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Executive  Summary 


Building  on  relevant  best  practices  extracted  from  the  Capability  Maturity  Model*  Integration 
(CMMI*)  Framework,  this  report  defines  effective  and  efficient  practices  for  government  acquisition 
organizations.  Acquisition  best  practices  are  focused  inside  the  acquisition  organization  to  ensure  the 
acquisition  is  conducted  effectively,  and  outside  the  acquisition  organization  as  it  conducts  project 
monitoring  and  control  of  its  suppliers.  These  best  practices  provide  a  foundation  for  acquisition  proc' 
ess  disciphne  and  rigor  that  enables  product  and  service  development  to  be  repeatedly  executed  with 
high  levels  of  ultimate  acquisition  success. 

This  report  contains  the  acquisition  practices  that  should  be  performed  by  government  acquisition  or- 
ganizations  acquiring  systems  and/or  services.  These  practices,  however,  can  also  be  used  by  non- 
government  organizations  to  improve  their  acquisition  practices.  This  report  does  not  contain  prc' 
scribed  implementation  approaches  for  achieving  acquisition  best  practices.  Instead,  the  proven  con' 
tent  of  the  CMMI  Framework  is  used  as  a  base  and  amplifications  specific  to  the  acquisition  process 
are  added. 

Questions  related  to  CMMI  process  areas  are  provided  in  the  appendix  to  help  managers  and  execu¬ 
tives  understand  the  acquisition  organization’s  documented  acquisition  practices  and  the  consistent 
application  of  those  practices.  Descriptions  of  implementation  details  can  be  found  in  the  source 
documents  listed  in  the  bibliography. 


Capability  Maturity  Model  and  CMMI  are  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mel¬ 
lon  University. 
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1  Introduction 


The  CMMI  Acquisition  Module  (CMMI'AM)  focuses  on  effective  acquisition  activities  and  practices  that 
are  implemented  by  first-level  acquisition  projects  (e.g..  System  Project  Office/Program  Manager). 
This  report  also  is  intended  to  provide  guidance  to  acquisition  organizations  above  the  acquisition 
project  level  to  support  their  insight  into  an  acquisition  project’s  practices  and  the  institutionaliza¬ 
tion  of  those  acquisition  practices. 

1.1  Purpose  and  Goals 

Acquisition  activities  are  complex  because  acquisition  is  both  outwardly  directed  toward  acquiring 
products,  systems,  and  services,  and  inwardly  directed  toward  conducting  the  acquisition  process 
itself.  As  a  result,  this  module  defines  the  essential  practices  required  to  perform  acquisition  activi¬ 
ties,  but  recognizes  that  many  of  those  practices  are  performed  slightly  differently  or  with  differing 
roles  when  focused  either  internally  or  externally.  These  differences  are  particularly  apparent  in  ac¬ 
tivities  such  as  monitoring,  directing,  or  overseeing  the  seleeted  supplier,  which  occur  after  a  source 
selection  is  completed. 

Lack  of  acquisition  guidance  is  a  major  concern  for  government  organizations  involved  in  the  acqui¬ 
sition  and  sustainment  of  systems,  including  software-intensive  systems.  Over  the  past  decade,  much 
of  the  headquarters  and  field-level  acquisition  guidance  for  systems  and  software  acquisition  and 
sustainment  has  been  rescinded,  simplified,  or  reduced  in  scope  such  that  only  minimal  acquisition- 
related  guidance  remains  in  many  acquisition  areas. 

This  reduction  of  guidance  has  occurred  as  system  complexity  and  the  software  contribution  to 
overall  system  functionahty  rises  to  unprecedented  levels.  System  development  efforts  are  also  chal¬ 
lenged  to  meet  estabhshed  performance,  cost,  and  schedule  basehnes.  At  the  same  time,  there  are 
demands  for  drastic  decreases  in  acquisition  cycle  times  as  well  as  improved  credibility  as  govern¬ 
ment  leaders  work  to  create  an  environment  of  maximum  flexibihty  for  acquisition  projects.  These 
changes  in  complexity  and  demands  for  agile  product  adaptability  and  shortened  dehvery  timeframes 
place  stress  on  existing  acquisition  practices. 

Congressional-  and  DOD-level  guidance  continues  to  emphasize  software  acquisition  process  im¬ 
provement,  including  the  measurement  of  process  performance  by  acquisition  organizations.  While 
some  of  these  driving  forces  seem  inconsistent,  one  way  to  meet  the  intent  of  those  wishing  to  im¬ 
prove  acquisition  practices  is  to  build  systems  right  the  first  time  through  the  disciphned  application 
of  effective  acquisition  processes.  This  approach  requires  a  renewed  dedication  to  ensuring  that  the 
acquisition  processes  fundamental  to  a  technically  sound  project  are  defined,  implemented,  meas¬ 
ured,  and  maintained. 

It  is  the  goal  of  this  document  to  define  effective  and  efficient  acquisition  practices,  both  directed 
internally  toward  the  acquisition  project  and  directed  externally  toward  the  project  monitoring  and 
control  of  the  selected  supplier.  These  practices  are  intended  to  provide  a  basis  for  acquisition  proc¬ 
ess  discipline  whUe  balancing  the  need  for  agility.  This  report  identifies  those  acquisition  practices 
that  should  be  performed,  but  does  not  prescribe  specific  implementation  approaches. 


CMU/SEI-2004-TR-001 


1 


1 .2  Acquisition  Processes  and  Practices 

Acquisition  organizations  and  projects  perform  a  number  of  basic  processes  in  achieving  success. 
These  processes  are  described  generically  to  support  the  numerous  variations  in  application  that  oc- 
cur  among  acquisition  organizations.  In  some  cases,  the  practices  included  herein  are  performed  at 
varying  degrees  by  both  the  acquisition  team  and  the  supplier  team  during  the  program  life  cycle. 
Because  variations  in  execution  are  at  the  discretion  of  the  acquisition  organization,  it  is  the  intent  of 
this  module  to  focus  on  “what”  should  be  done,  not  “how”  it  is  done. 

The  acquisition  team  for  any  given  program  may  execute  these  practices  directly,  delegate  them  to 
another  organization,  or  assign  a  larger  degree  of  responsibihty  for  the  activities  to  the  suppher. 
Many  of  these  acquisition  practices  and  amplifications  are  drawn  and  summarized  from  existing 
sources  of  best  practices,  including  the  Software  Acquisition  Capability  Maturity  Model  (SA- 
CMM*),  the  Capabihty  Maturity  Model  Integration  (CMMI)  Framework,  the  Federal  Aviation  Ad' 
ministration  (FAA)  Integrated  Capability  Maturity  Model  (iCMM),  as  well  as  additional  coverage 
areas  defined  by  experienced  acquisition  professionals.  References  to  these  sources  are  provided  in 
the  bibhography. 

1.3  Terminology  and  References  to  CMMi  Content 

In  general,  this  module  uses  the  terminology  contained  within  the  CMMI  Framework  and  contains 
amplified  text  from  that  framework.  Rather  than  creating  a  set  of  recommended  processes  and  prac¬ 
tices  from  scratch,  this  module  utihzes  proven  content  derived  from  the  CMMI  Framework  and  adds 
amplifications  specific  to  the  acquisition  process  to  address  the  unique  facets  of  acquisition. 

Throughout  this  module,  there  are  references  to  the  CMMI  Product  Suite  and  the  CMMI  Framework 
to  allow  an  interested  reader  to  explore  additional  material  on  collectively  understood  best  practices. 
References  to  CMMI  products  wiU  be  more  easily  utilized  if  the  following  definitions  and  terms  are 
understood  from  both  the  acquisition  and  the  process  improvement  contexts. 

For  further  reference  to  the  CMMI  Framework,  see  the  Capability  Maturity  Model  Integration 
(CMMI)  model  that  contains  all  currently  published  disciplines,  namely  CMMI  for  Systems  Engineering, 
Software  Engineering,  Integrated  Product  and  Process  Development  and  Supplier  Sourcing  (CMMI- 
SE/SW/IPPD/SS),  Version  1.1  Continuous  Representation,  released  in  March  2002.  The  continuous 
representation  structures  the  process  areas  in  groupings  related  to  Process  Management,  Project 
Management,  Engineering,  and  Support.  In  general,  this  CMMI  Acquisition  Module  mainly  emphasizes 
Project  Management,  Engineering,  and  Support  process  areas.  The  Process  Management  process  ar¬ 
eas  provide  details  on  how  to  define  and  improve  processes  without  regard  to  the  application  area 
(e.g.,  product  development,  acquisition)  and  were  excluded  from  this  document  for  readability  pur¬ 
poses.  You  are  encouraged  to  explore  the  CMMI  Framework  for  more  information. 

In  the  CMMI  Product  Suite, 

•  The  term  ‘project’  is  used  to  specify  all  activities  related  to  complete  an  acquisition.  From  the 
acquisition  perspective,  a  project  (or  program,  depending  on  local  interpretation),  when  used  in 
this  module,  refers  to  the  entire  acquisition  project  or,  perhaps,  major  subsets  of  the  acquisition 
project.  The  scope  of  the  term  is  tailored  to  the  specific  acquisition  opportunity. 


CMM  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  University. 
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•  The  term  ‘organization’  is  typically  used  to  specify  an  administrative  structure  in  which  people 
collectively  manage  one  or  more  projects.  Those  projects  share  a  senior  manager  and  operate 
under  the  same  policies. 

1.4  Integrated  Product  and  Process  Development 

The  CMMI  Accfuhition  Module  embeds  the  concepts  of  Integrated  Product  and  Process  Development 
(IPPD)  throughout.  IPPD  is  a  systematic  approach  that  achieves  a  timely  collaboration  of  relevant 
stakeholders  throughout  the  life  of  the  product  to  better  satisfy  customer  needs,  expectations,  and 
requirements.  Some  of  these  concepts  are  described  in  explicit  practices  found  in  process  areas. 
These  concepts  include: 

•  effective  use  of  cross-functional  or  multidisciplinary  teams 

•  leadership  commitment 

•  appropriate  allocation  and  delegation  of  decision  making 

•  definition  of  organizational  structures  that  reward  team  performance 

Other  IPPD  concepts  are  integral  parts  of  the  entire  module.  These  concepts  include: 

•  design  of  downstream  processes  (e.g.,  transition  to  operations  and  support)  during  the  acquisition 

•  focus  on  the  customers’  needs  during  the  acquisition 

•  timely  and  appropriate  collaboration  of  all  relevant  stakeholders 

•  continuous  and  proactive  identification  and  management  of  risk 

•  focus  on  measurement  and  improvement  of  processes  to  develop  and  deliver  the  product 
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2  Acquisition  Process  Areas 


The  acquisition  process  areas  in  this  section  are  abstracted  from  a  number  of  sources,  principally  the 
CMMI  Framework,  the  Software  Acquisition  CMM  and  the  FAA’s  iCMM.  Amplifications  related 
specifically  to  acquisition  have  been  added  in  the  shaded  text  areas.  These  amplifications  are  de- 
signed  to  put  into  context  the  best  practices  of  the  source  models  for  use  in  acquisition  organiza- 
tions. 

The  process  areas  included  in  this  section  represent  a  minimal  set  of  processes  that  cover  the  best 
practices  needed  to  successfully  address  the  entire  acquisition  life  cycle.  Each  acquisition  project  op¬ 
erates  within  a  unique  environment  that  influences  the  life-cycle  definition.  The  acquisition  hfe  cy¬ 
cle,  especially  as  it  applies  to  upgrades  and  modifications,  may  restart  after  a  cycle  has  been  initiated 
and  partially  completed.  For  example,  acquisition  of  a  major  upgrade  may  be  initiated  to  a  system 
that  has  already  been  developed,  fielded,  and  placed  into  operation.  In  such  cases,  the  application  of 
this  module  could  result  in  considering  the  upgrade  acquisition  as  a  new  acquisition  hfe  cycle  with 
complex  implementation  requirements  that  may  impact  another  acquisition  hfe  cycle  already  un¬ 
derway.  Or,  in  other  cases,  the  acquisition  hfe  cycle  may  continue  throughout  the  product’s  hfe  cycle 
through  disposal. 

2.1  Configuration  Management 

The  purpose  of  Configuration  Management  is  to  estabhsh  and  maintain  the  integrity  of  work  prod¬ 
ucts  using  configuration  identification,  configuration  control,  configuration  status  accounting,  and 
configuration  audits. 

For  acquisition,  work  products  such  as  solicitation  packages,  which  arc  created  by  the  acquisition  project,  are  placed 
under  configuration  management  internally.  In  addition,  configuration  management  of  acquired  products  (both  final 
and  interim  products)  created  by  the  primary  and  subordinate  suppliers  require  monitoring  to  ensure  that  project  goals 
are  met.  The  acquisition  project  should  ensure  that  provisions  are  made  for  conducting  configuration  management  of 
supplier  products  and  documentation.  Methods  to  ensure  that  the  data  created  by  the  acquisition  project  is  complete  and 
consistent  should  be  established  and  maintained.  It  is  left  to  the  acquisition  project  to  determine  which  work  products 
are  controlled  using  configuration  management  processes. 

Configuration  Management  generally  involves  the  following: 

•  identifying  the  configuration  of  selected  work  products  that  compose  the  baselines  at  given  points 
in  time 

•  controlling  changes  to  configuration  items 

•  building  or  providing  specifications  to  build  work  products  from  the  configuration  management 
system 

•  maintaining  the  integrity  of  baselines 

•  providing  accurate  status  and  current  configuration  data  to  developers,  end  users,  and  customers 
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The  work  products  placed  under  configuration  management  include  designated  internal  work  prod- 
ucts  created  by  the  acquirer,  acquired  products,  tools,  and  other  items  that  are  used  by  either  the  ac- 
quirer  or  the  supplier  in  creating  and  describing  these  work  products. 

Configuration  Management  can  be  best  described  by  the  following  goals  and  practices.  The  process 
area’s  goals  are  bold  and  the  practices  are  numbered  sequentially  below  each  goal. 

1.  Baselines  of  identified  work  products  are  established. 

1 . 1  Identify  the  configuration  items,  components,  and  related  work  products  that  will  be  placed 
under  configuration  management. 

1 .2  Establish  and  maintain  a  configuration  management  and  change  management  system  for 
controlling  work  products. 

1.3  Create  or  release  baselines  for  internal  use  and  for  delivery  to  the  customer. 

2.  Changes  to  the  work  products  under  configuration  management  are  tracked  and  controlled. 

2. 1  Track  change  requests  for  the  configuration  items. 

2.2  Control  changes  to  the  configuration  items. 

3.  Integrity  of  baselines  is  established  and  maintained. 

3.1  Establish  and  maintain  records  describing  configuration  items. 

3.2  Perform  configuration  audits  to  maintain  integrity  of  the  configuration  baselines. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Configuration  Management,  see  the 
source  documents  referenced  in  the  bibliography. 

2.2  Decision  Anaiysis  and  Resoiution 

The  purpose  of  Decision  Analysis  and  Resolution  is  to  analyze  possible  decisions  using  a  formal 
evaluation  process  that  evaluates  identified  alternatives  against  established  criteria. 

For  acquisition,  a  repeatable  criteria'based  decision-making  process  is  especially  important,  both  while  making  the 
critical  decisions  that  define  and  guide  the  acquisition  process  itself  and  later  when  critical  decisions  arc  made  with  the 
selected  supplier.  The  establishment  of  a  formal  process  for  decision-making  provides  the  acquisition  project  with  docu¬ 
mentation  of  the  decision  rationale.  Such  documentation  allows  the  criteria  for  critical  decisions  to  be  revisited  when 
changes  or  technology  insertion  decisions  that  impact  essential  requirements  are  considered. 

The  Decision  Analysis  and  Resolution  process  area  involves  estabhshing  guidelines  to  determine 
which  issues  should  be  subjected  to  a  formal  evaluation  process  and  then  applying  formal  evaluation 
processes  to  these  issues. 

A  formal  evaluation  process  is  a  structured  approach  to  evaluating  alternative  solutions  against  es' 
tablished  criteria  to  determine  a  recommended  solution  to  address  an  issue.  A  formal  evaluation 
process  involves  the  following  actions: 

•  establishing  the  criteria  for  evaluating  alternatives 

•  identifying  alternative  solutions 

•  selecting  methods  for  evaluating  alternatives 

•  evaluating  the  alternative  solutions  using  the  established  criteria  and  methods 
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•  selecting  recommended  solutions  from  the  alternatives  based  on  the  evaluation  criteria 

Rather  than  using  the  phrase  “alternative  solutions  to  address  issues”  each  time  it  is  needed,  we  will 
use  one  of  two  shorter  phrases:  “alternative  solutions”  or  “alternatives.” 

A  formal  evaluation  process  reduces  the  subjective  nature  of  the  decision  and  has  a  higher  probability 
of  selecting  a  solution  that  meets  the  multiple  demands  of  the  relevant  stakeholders. 

While  the  primary  application  of  this  process  area  is  for  selected  technical  concerns,  formal  evalua- 
tion  processes  can  also  be  applied  to  many  non-technical  issues,  particularly  when  a  project  is  being 
planned.  Issues  that  have  multiple  alternative  solutions  and  evaluation  criteria  lend  themselves  to  a 
formal  evaluation  process. 

Trade  studies  of  equipment  or  software  are  typical  examples  of  formal  evaluation  processes. 

During  planning,  specific  issues  requiring  a  formal  evaluation  process  are  identified.  Typical  issues 
include  selection  among  architectural  or  design  alternatives,  use  of  reusable  or  commercial  offrthe' 
shelf  (COTS)  components,  supplier  selection,  engineering  support  environment  development  or  as- 
sociated  tool  selection,  test  environment  development,  and  logistics  and  production.  A  formal  evalua- 
tion  process  can  also  be  used  to  address  a  make-or-buy  decision,  the  development  of  manufacturing 
processes,  the  selection  of  distribution  locations,  and  other  decisions. 

Guidelines  are  created  for  deciding  when  to  use  formal  evaluation  processes  to  address  unplanned 
issues.  Guidelines  often  suggest  using  formal  evaluation  processes  when  issues  are  associated  with 
medium  to  high  risks  or  when  issues  affect  the  ability  to  achieve  project  objectives. 

Formal  evaluation  processes  can  vary  in  formality,  type  of  criteria,  and  methods  employed.  Less  for¬ 
mal  decisions  can  be  analyzed  in  a  few  hours,  use  only  a  few  criteria  (e.g.,  effectiveness  and  cost  to 
implement),  and  result  in  a  one-  or  two-page  report.  More  formal  decisions  may  require  separate 
plans,  months  of  effort,  meetings  to  develop  and  approve  criteria,  simulations,  prototypes,  piloting, 
and  extensive  documentation. 

Both  numeric  and  non-numeric  criteria  can  be  used  in  a  formal  evaluation  process.  Numeric  criteria 
use  weights  to  reflect  the  relative  importance  of  the  criteria.  Non-numeric  criteria  use  a  more  subjec¬ 
tive  ranking  scale  (e.g.,  high,  medium,  low).  More  formal  decisions  may  require  a  full  trade  study. 

A  formal  evaluation  process  identifies  and  evaluates  alternative  solutions.  The  eventual  selection  of  a 
solution  may  involve  iterative  activities  of  identification  and  evaluation.  Portions  of  identified  alter¬ 
natives  may  be  combined,  emerging  technologies  may  change  alternatives,  and  the  business  situation 
for  vendors  may  change  during  the  evaluation  period. 

A  recommended  alternative  is  accompanied  by  documentation  of  the  selected  methods,  criteria,  al¬ 
ternatives,  and  rationale  for  the  recommendation.  The  documentation  is  distributed  to  the  relevant 
stakeholders;  it  provides  a  record  of  the  formal  evaluation  process  and  rationale  useful  to  other  pro¬ 
jects  that  encounter  a  similar  issue. 

Decision  Analysis  and  Resolution  can  best  be  described  by  the  following  goals  and  practices.  Goals 
are  shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 
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1.  Decisions  are  based  on  an  evaluation  of  alternatives  using  established  criteria. 

1 . 1  Establish  and  maintain  guidelines  to  determine  which  issues  are  subject  to  a  formal 
evaluation  process. 

1 .2  Establish  and  maintain  the  criteria  for  evaluating  alternatives,  and  the  relative  ranking  of 
these  criteria. 

1.3  Identify  alternative  solutions  to  address  issues. 

1 .4  Select  the  evaluation  methods. 

1 .5  Evaluate  alternative  solutions  using  the  established  criteria  and  methods. 

1 .6  Select  solutions  from  the  alternatives  based  on  the  evaluation  criteria. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Decision  Analysis  and  Resolution,  see  the 
source  documents  referenced  in  the  bibliography. 

2.3  Integrated  Project  Management 

The  purpose  of  Integrated  Project  Management  is  to  establish  and  manage  the  project  and  the  in¬ 
volvement  of  the  relevant  stakeholders  according  to  an  integrated  and  defined  process  that  is  tailored 
from  the  organization's  set  of  standard  processes.  Integrated  Project  Management  also  covers  the 
establishment  of  a  shared  vision  for  the  project  and  a  team  structure  for  integrated  teams  that  will 
carry  out  the  objectives  of  the  project. 

For  acquisition.  Integrated  Project  Management  involves  establishing  project  management  processes  consistent  with 
and  tailored  from  the  organization’s  standard  processes.  This  includes  higher  level  acquisition  guidance,  regulations, 
instructions,  as  well  as  local  practices  established  to  be  used  across  various  projects  in  the  local  organization.  Establish' 
ing  an  integrated  project  management  process  that  incorporates  and  involves  all  stakeholders  (executive  level  acquisi¬ 
tion  offices,  users,  test  organizations,  developers,  and  associated  government  support  organizations)  is  critical  to  the 
successful  development  of  the  project.  This  defined  project  management  process  is  typically  defined  in  an  overall  project 
management  plan  or  equivalent  document. 

The  integrated  project  management  process  needs  to  involve  and  integrate  all  affected  acquisition,  development,  support, 
and  operational  activities.  Depending  on  the  size  of  the  project,  the  size  of  the  coordination  efforts  can  be  significant. 

Formal  interfaces  among  project  stakeholders  take  the  form  of  memorandums  of  understanding  (MOUs),  memoran¬ 
dums  of  agreements  (MOAs),  contractual  commitments,  associate  contractor  agreements,  and  similar  documents,  de¬ 
pending  on  the  nature  of  the  interfaces  and  involved  stakeholders. 

The  project's  defined  process  includes  all  life-cycle  processes  including  the  IPPD  processes  that  are  applied  by  the  project 
(tailored  from  the  organization's  IPPD  processes).  Processes  to  select  the  team  structure,  allocate  limited  personnel 
resources,  implement  cross-integrated  team  communication,  and  conduct  issue-resolution  processes  are  part  of  the  pro¬ 
ject's  defined  process. 

The  plans  of  the  integrated  teams  are  included  in  this  integration.  Developing  a  complete  project  plan  and  the  project's 
defined  process  may  require  an  iterative  effort  if  a  complex,  multi-layered,  integrated  team  structure  is  being  deployed. 

Managing  the  project’s  effort,  cost,  schedule,  performance,  capability,  staffing,  risks,  and  other  fac¬ 
tors  is  tied  to  the  tasks  of  the  project's  defined  process.  The  implementation  and  management  of  the 
project's  defined  process  are  typically  described  in  the  project  plan.  Certain  activities  may  be  covered 
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in  other  plans  that  affect  the  project,  such  as  the  quality  assurance  plan,  risk  management  strategy, 
and  the  configuration  management  plan. 

Since  the  defined  process  for  each  project  is  tailored  from  the  organization's  set  of  standard  proc' 
esses,  variability  among  projects  is  typically  reduced  and  projects  can  more  easily  share  process  as- 
sets,  data,  and  lessons  learned. 

This  process  area  also  addresses  the  coordination  of  aU  activities  associated  with  the  project  includ¬ 
ing  the  following: 

•  technical  activities  such  as  requirements  development,  design,  and  verification 

•  support  activities  such  as  configuration  management,  documentation,  and  training 

The  working  interfaces  and  interactions  among  relevant  stakeholders  internal  and  external  to  the 
project  are  planned  and  managed  to  ensure  the  quality  and  integrity  of  the  entire  product.  Relevant 
stakeholders  participate,  as  appropriate,  in  defining  the  project’s  defined  process  and  the  project 
plan.  Reviews  and  exchanges  are  regularly  conducted  with  the  relevant  stakeholders  and  coordina¬ 
tion  issues  receive  appropriate  attention.  In  defining  the  project’s  defined  process,  formal  interfaces 
are  created  as  necessary  to  ensure  that  appropriate  coordination  and  collaboration  occurs. 

This  process  area  apphes  in  any  organizational  structure,  including  projects  that  are  structured  as 
line  organizations,  matrix  organizations,  or  integrated  teams.  The  terminology  should  be  appropri¬ 
ately  interpreted  for  the  organizational  structure  in  place. 

Integrated  Project  Management  is  best  described  by  the  following  goals  and  practices.  Goals  are 
shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  The  project  is  conducted  using  a  deflned  process  that  is  tailored  from  the  organization’s  set 
of  standard  processes. 

It  is  possible  that  an  organization  has  not  established  a  standard  set  of  processes.  If  so,  the  project  should  define  its  own 
processes  appropriate  to  their  need. 

1 . 1  Establish  and  maintain  the  project’s  defined  process. 

1 .2  Use  the  organizational  process  assets  and  measurement  repository  for  estimating  and 
planning  the  project’s  activities. 

1 .3  Integrate  the  project  plan  and  the  other  plans  that  affect  the  project  to  describe  the  project’s 
defined  process. 

1.4  Manage  the  project  using  the  project  plan,  the  other  plans  that  affect  the  project,  and  the 
project’s  defined  process. 

1 .5  Contribute  work  products,  measures,  and  documented  experiences  to  the  organizational 
process  assets. 

2.  Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  are  conducted. 

2. 1  Manage  the  involvement  of  the  relevant  stakeholders  in  the  project. 

2.2  Participate  with  relevant  stakeholders  to  identify,  negotiate,  and  track  critical  dependencies. 

2.3  Resolve  issues  with  relevant  stakeholders. 
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3.  The  project  is  conducted  using  the  project’s  shared  vision. 

3.1  Identify  expectations,  constraints,  interfaces,  and  operational  conditions  applicable  to  the 
project’s  shared  vision. 

3.2  Establish  and  maintain  a  shared  vision  for  the  project. 

4.  The  integrated  teams  needed  to  execute  the  project  are  identified,  defined,  structured,  and 
tasked. 

4. 1  Determine  the  integrated  team  structure  that  will  best  meet  the  project  objectives  and 
constraints. 

4.2  Develop  a  preliminary  distribution  of  requirements,  responsibilities,  authorities,  tasks,  and 
interfaces  to  teams  in  the  selected  integrated  team  structure. 

4.3  Establish  and  maintain  teams  in  the  integrated  team  structure. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Integrated  Project  Management,  see  the 
source  documents  referenced  in  the  bibliography. 

2.4  Integrated  Teaming 

The  purpose  of  Integrated  Teaming  is  to  form  and  sustain  an  integrated  team  for  the  development  of 
work  products. 

For  acquisition,  Integrated  Teaming  should  consider  the  overall  scope  of  and  requirement  for  participation  of  stake' 
holders  from  users,  acquisition  executives,  acquisition  organizations,  developers  (primes,  associate  subcontractors, 
suppliers,  and  vendors),  test  organizations,  and  other  support  organizations  in  the  establishment  of  the  integrated  team 
structure  for  the  project.  The  function  of  each  team  should  drive  the  inclusion  of  the  appropriate  stakeholders  to  provide 
the  coverage  and  representation  required  for  team  success. 

The  establishment  of  the  processes  to  be  used  by  the  team  is  a  significant  issue  that  should  be  addressed.  For  example, 
does  the  team  adopt  a  common  process  for  team  operation  or  rely  on  each  team  member  to  use  his  or  her  own  organizU' 
tion’s  processes?  An  example  of  this  would  be  the  decision  regarding  the  software  development  processes  to  be  used  by 
each  developer  (a  common  process  across  the  team’s  developas  or  a  unique  but  compatible  process  for  each  developer). 
At  the  very  least,  the  various  team  member  processes  should  be  compatible  at  the  interface  points  of  the  team  member 
processes.  For  example,  the  process  used  by  the  acquirer  for  oversight  should  be  compatible  with  and  derive  data  from 
the  supplier’s  selected  processes  and  not  require  a  duplicate  process  to  be  used  to  generate  data  for  acquisition  project 
use  that  is  not  used  internally  by  the  supplier  for  day-tO'day  operation. 

Life'cycle  support  considerations  should  also  drive  the  selection  of  processes  across  the  team  members  in  areas  such  as 
tools  and  support  data  commonality  and  compatibility. 

Integrated  information  infrastructures  to  facilitate  communication  and  coordination  within  and  external  to  the  team, 
especially  those  related  to  geographically  separated  team  members  and  shareholders,  are  also  required.  These  may  in' 
volve  multiple  solutions  including,  for  example,  telecommunications,  electronic  data  sharing,  automated  collaboration 
tools,  and  regular  team  meetings. 

Integrated  team  members: 

•  provide  the  needed  skills  and  expertise  to  accomplish  the  team’s  tasks 
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•  provide  the  advocacy  and  representation  necessary  to  address  all  essential  phases  of  the  product’s 
life  cycle 

•  collaborate  internally  and  externally  with  other  teams  and  relevant  stakeholders  as  appropriate 

•  share  a  common  understanding  of  the  team’s  tasks  and  objectives 

•  conduct  themselves  in  accordance  with  established  operating  principles  and  ground  rules 

An  integrated  team  (also  known  as  an  “Integrated  Product  Team”  or  IPT)  is  composed  of  relevant 
stakeholders  who  generate  and  implement  decisions  for  the  work  product  being  developed.  The 
members  of  the  integrated  team  are  collectively  responsible  for  delivering  the  work  product.  The  in- 
tegrated  team  receives  its  assignment  from  its  sponsor.  The  sponsor  of  an  integrated  team  is  a  person 
or  a  group  (e.g.,  project  manager  or  even  another  integrated  team)  who  can  assign  work  tasks  and 
provide  resources. 

The  following  characteristics  distinguish  an  integrated  team  from  other  forms  of  specialty  work  or 
task  groups; 

•  Team  members  include  empowered  representatives  from  both  technical  and  business  functional 
organizations  involved  with  the  product.  Within  defined  boundaries,  these  representatives  have 
decision-making  authority  and  the  responsibility  to  act  for  their  respective  organizations. 

•  Team  members  may  include  customers,  suppliers,  and  other  stakeholders  outside  of  the  organiza¬ 
tion  as  appropriate  to  the  product  being  developed. 

•  An  integrated  team  consists  of  people  skilled  in  the  functions  that  need  to  be  performed  to  de¬ 
velop  required  work  products.  Some  of  them  may  represent  a  functional  organization.  These  peo¬ 
ple  have  a  dual  responsibility  to  focus  on  the  product  while  maintaining  their  connections  with 
the  functional  organization  that  can  assist  the  development  with  additional  expertise  and  advice. 

•  An  integrated  team  focuses  on  the  product  life  cycle  to  the  extent  required  by  the  project.  Team 
members  share  and  integrate  considerations,  expectations,  and  requirements  of  the  product  life- 
cycle  phases. 

•  An  integrated  team  understands  its  role  in  the  structure  of  teams  for  the  overall  project. 

•  Clearly  defined  and  commonly  understood  objectives,  tasks,  responsibilities,  authority,  and  con¬ 
text  (of  vertical  and  horizontal  interfaces)  provide  a  strong  basis  for  implementing  integrated 
teams. 

Integrated  Teaming  can  best  be  described  by  the  following  activities.  Goals  are  shown  in  bold  and 
practices  are  numbered  sequentially  below  each  goal. 

1.  A  team  composition  that  provides  the  knowledge  and  skills  required  to  deliver  the  team’s 
product  is  established  and  maintained. 

1 . 1  Identify  and  define  the  team’s  specific  internal  tasks  to  generate  the  team’s  expected  output. 

1 .2  Identify  the  knowledge,  skills,  and  functional  expertise  needed  to  perform  team  tasks. 

1 .3  Assign  the  appropriate  personnel  to  be  team  members  based  on  required  knowledge  and 
skills. 

2.  Operation  of  the  integrated  team  is  governed  according  to  established  principles. 

2. 1  Establish  and  maintain  a  shared  vision  for  the  integrated  team  that  is  aligned  with  any 
overarching  or  higher  level  vision. 
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2.2  Establish  and  maintain  a  team  charter  based  on  the  integrated  team’s  shared  vision  and 
overall  team  objectives. 

2.3  Clearly  define  and  maintain  each  team  member’s  roles  and  responsibilities. 

2.4  Establish  and  maintain  integrated  team  operating  procedures. 

2.5  Establish  and  maintain  collaboration  among  interfacing  teams. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Integrated  Teaming,  see  the  source  docu' 
ments  referenced  in  the  bibliography. 

2.5  Measurement  and  Analysis 

The  purpose  of  Measurement  and  Analysis  is  to  develop  and  sustain  a  measurement  capability  that  is 
used  to  support  management  information  needs. 

For  acquisition,  the  acquisition  project  has  information  needs  for  determining  the  status  of  its  activities  throughout  the 
life  cycle  of  the  acquisition,  the  supplier’s  activities  per  contractual  requirements,  as  well  as  the  status  of  the  evolving 
products  acquired.  In  acquisition  projects  where  multiple  products  are  acquired  to  deliver  a  capability  to  the  end  user, 
or  where  there  are  teaming  relationships  with  other  acquisition  projects  to  acquire  joint  capabilities,  additional  infor¬ 
mation  needs  may  be  identified  to  ensure  programmatic,  technical,  and  operational  interoperability  objectives  are  iden¬ 
tified,  measured,  and  achieved. 

The  Measurement  and  Analysis  process  area  involves  the  following: 

•  specifying  the  objectives  of  measurement  and  analysis  such  that  they  are  aligned  with  identified 
information  needs  and  objectives 

•  specifying  the  measures,  data  collection  and  storage  mechanisms,  analysis  techniques,  and 
reporting  and  feedback  mechanisms 

•  implementing  the  collection,  storage,  analysis,  and  reporting  of  the  data 

•  providing  objective  results  that  can  be  used  in  making  informed  decisions  and  taking  appropriate 
corrective  actions 

The  integration  of  measurement  and  analysis  activities  into  the  processes  of  the  project  supports  the 
following: 

•  objective  planning  and  estimating 

•  tracking  actual  performance  against  established  plans  and  objectives 

•  identifying  and  resolving  process-related  issues 

•  providing  a  basis  for  incorporating  measurement  into  additional  processes  in  the  future 

The  staff  required  to  implement  a  measurement  capability  may  or  may  not  be  employed  in  a  separate 
organization-veide  project.  Measurement  capabihty  may  be  integrated  into  individual  projects  or 
other  organizational  functions  (e.g.,  Quahty  Assurance). 

The  initial  focus  for  measurement  activities  is  at  the  project  level.  However,  a  measurement  capabil¬ 
ity  may  prove  useful  for  addressing  organization-  and/or  enterprise-wide  information  needs. 
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Projects  may  choose  to  store  project-specific  data  and  results  in  a  project'specific  repository.  When 
data  are  shared  more  widely  across  projects,  the  data  may  reside  in  the  organization’s  measurement 
repository. 

Measurement  and  Analysis  can  best  be  described  by  the  following  goals  and  practices.  Goals  are 
shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  Measurement  objectives  and  activities  are  aligned  with  identified  information  needs  and 
objectives. 

1 . 1  Establish  and  maintain  measurement  objectives  that  are  derived  from  identified  information 
needs  and  objectives. 

1 .2  Specify  measures  to  address  the  measurement  objectives. 

1 .3  Specify  how  measurement  data  will  be  obtained  and  stored. 

1 .4  Specify  how  measurement  data  will  be  analyzed  and  reported. 

2.  Measurement  results  that  address  identified  information  needs  and  objectives  are  provided. 

2. 1  Obtain  specified  measurement  data. 

2.2  Analyze  and  interpret  measurement  data. 

2.3  Manage  and  store  measurement  data,  measurement  specifications,  and  analysis  results. 

2.4  Report  results  of  measurement  and  analysis  activities  to  all  relevant  stakeholders. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Measurement  and  Analysis,  see  the  source 
documents  referenced  in  the  bibliography. 

2.6  Organizational  Environment  for  Integration 

The  purpose  of  Organizational  Environment  for  Integration  is  to  provide  an  IPPD  infrastructure  and 
manage  people  for  integration. 

For  acquisition.  Organization  Environment  for  Integration  is  an  important  element  establishing  an  environment  where 
integrated  teams  are  used.  Practices  in  this  process  area  provide  the  infrastructure  to  establish  fully  functional  teams 
from  among  all  stakeholders  (acquisition project,  supplier,  and  other  supporting  organizations). 

For  acquisition,  there  are  two  focuses  on  integration — Technical  and  Organizational.  To  achieve  integrated  product 
integration,  the  technical  aspects  of  the  project  must  be  brought  together  and  holistically  considered  by  all  elements  of 
the  project.  If  appropriate  decisions  are  to  be  reached,  technical  capabilities  and  requirements  must  be  examined  and 
understood  as  they  relate  to  the  project’s  overall  goals  and  objectives.  To  achieve  organizational  integration,  the  project 
entities  must  operate  with  a  single  vision  and  a  cooperative  purpose.  When  establishing  the  goals  and  objectives  of  each 
of  the  entities,  the  project  members  involved  must  be  cognizant  of  both  the  interrelationships  of  all  aspects  of  the  project 
and  how  they  relate  to  the  specific  goals  and  objectives  of  the  entity. 

Successful  integration  of  the  business  and  technical  elements  of  projects  is  dependent  upon  substan- 
tive  and  proactive  organizational  processes  and  guidelines.  The  organization  is  an  integrated  system 
capable  of  providing  and  sustaining  the  people,  products,  and  processes  necessary  for  the  effective 
and  efficient  execution  of  its  projects.  The  organization  should  raise  performance  expectations  from 
all  projects  while  providing  mechanisms  that  stimulate  both  team  and  individual  excellence. 
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Important  characteristics  of  effective  environments  for  integration  include  people  trained  to  exploit 
the  collaborative  environment;  a  workplace  that  provides  resources  to  maximize  the  productivity  of 
people  and  facihtate  integrated  teams;  and  a  set  of  organizational  standard  processes  and  organiza- 
tional  process  assets  that  culturally  enable  an  IPPD  environment  that  promotes  and  rewards  team  as 
weU  as  individual  excellence. 

Organizational  Environment  for  Integration  can  best  be  described  by  the  following  goals  and  prac' 
tices.  Goals  are  shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  An  infrastructure  that  maximizes  the  productivity  of  people  and  affects  the  coiiahoration 
necessary  for  integration  is  provided. 

1 . 1  Establish  and  maintain  a  shared  vision  for  the  organization. 

1.2  Establish  and  maintain  an  integrated  work  environment  that  supports  IPPD  by  enabling 
collaboration  and  concurrent  development. 

1 .3  Identify  the  unique  skills  needed  to  support  the  IPPD  environment. 

2.  People  are  managed  to  nurture  the  integrative  and  collaborative  behaviors  of  an  IPPD  envi¬ 
ronment. 

2. 1  Establish  and  maintain  leadership  mechanisms  to  enable  timely  collaboration. 

2.2  Establish  and  maintain  incentives  for  adopting  and  demonstrating  integrative  and 
collaborative  behaviors  at  all  levels  of  the  organization. 

2.3  Establish  and  maintain  organizational  guidelines  to  balance  team  and  home  organization 
responsibilities. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Organizational  Environment  for  Integra- 
tion,  see  the  source  documents  referenced  in  the  bibliography. 

2.7  Process  and  Product  Quality  Assurance 

The  purpose  of  Process  and  Product  Quality  Assurance  is  to  provide  staff  and  management  with  ob¬ 
jective  insight  into  processes  and  associated  work  products. 

For  acquisition,  the  products  and  processes  evaluated  are  those  of  the  acquisition  project.  For  example,  the  acquisition 
project  may  develop  and  maintain  a  solicitation  package.  The  process  and  product  quality  assurance  (PP^A)  function 
would  ensure  that  the  solicitation  package  was  developed  per  the  standard  or  format  agreed  to  by  the  project  team  and 
that  it  conforms  to  all  applicable  policies  and  laws.  As  a  process  evaluation,  thePP^A  function  may  evaluate  the  acquF 
sition  project’s  risk  management  process  against  their  plan  for  risk  management  to  ensure  the  project  is  effectively  im^ 
plemcnting  their  agreed  to  process.  In  most  cases,  the  PP^A  Junction  in  an  acquisition  project  is  not  performed  by  a 
quality  assurance  group  separate  from  the  project. 

The  Process  and  Product  Quahty  Assurance  process  area  involves  the  following; 

•  objectively  evaluating  performed  processes,  work  products,  and  services  against  the  applicable 
process  descriptions,  standards,  and  procedures 

•  identifying  and  documenting  noncompliance  issues 

•  providing  feedback  to  project  staff  and  managers  on  the  results  of  quality  assurance  activities 

•  ensuring  that  noncompliance  issues  are  addressed 
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The  Process  and  Product  Quality  Assurance  process  area  supports  the  acquisition  of  high-quality 
products  and  services  by  providing  the  project  staff  and  managers  at  all  levels  with  appropriate  visi- 
bflity  into,  and  feedback  on,  processes  and  associated  work  products  throughout  the  life  of  the  pro¬ 
ject. 

The  practices  in  the  Process  and  Product  Quality  Assurance  process  area  ensure  that  planned  proc¬ 
esses  are  implemented,  while  the  practices  in  the  Verification  process  area  ensure  that  the  specified 
requirements  are  satisfied.  These  two  process  areas  may  on  occasion  address  the  same  work  product 
but  from  different  perspectives.  Projects  should  take  care  to  minimize  duplication  of  effort. 

Objectivity  in  process  and  product  quahty  assurance  evaluations  is  critical  to  the  success  of  the  pro¬ 
ject.  Objectivity  is  achieved  by  both  independence  and  the  use  of  criteria.  Traditionally,  a  quality  as¬ 
surance  group  that  is  independent  of  the  project  provides  this  objectivity.  It  may  be  appropriate  in 
some  organizations,  however,  to  implement  the  process  and  product  quality  assurance  role  without 
that  kind  of  independence.  For  example,  in  an  organization  with  an  open,  quality-oriented  culture, 
the  process  and  product  quality  assurance  role  maybe  performed,  partially  or  completely,  by  peers; 
and  the  quality  assurance  function  may  be  embedded  in  the  process. 

If  quahty  assurance  is  embedded  in  the  process,  several  issues  should  be  addressed  to  ensure  objec¬ 
tivity.  Everyone  performing  quality  assurance  activities  should  be  trained  in  quality  assurance.  Those 
performing  quality  assurance  activities  for  a  work  product  should  be  separate  from  those  directly 
involved  in  developing  or  maintaining  the  work  product.  An  independent  reporting  channel  to  the 
appropriate  level  of  organizational  management  should  be  estabhshed  so  that  noncompliance  issues 
may  be  escalated  as  necessary. 

Quality  assurance  should  begin  in  the  early  phases  of  a  project  to  estabhsh  plans,  processes,  stan¬ 
dards,  and  procedures  that  will  add  value  to  the  project  and  satisfy  the  requirements  of  the  project 
and  the  organizational  pohcies.  Those  performing  quahty  assurance  participate  in  establishing  the 
plans,  processes,  standards,  and  procedures  to  ensure  that  they  fit  the  project’s  needs  and  that  they 
will  be  useable  for  performing  quahty  assurance  evaluations.  In  addition,  the  specific  processes  and 
associated  work  products  that  will  be  evaluated  during  the  project  are  designated.  This  designation 
may  be  based  on  sampling  or  on  objective  criteria  that  are  consistent  with  organizational  pohcies 
and  project  requirements  and  needs. 

When  noncompliance  issues  are  identified,  they  are  first  addressed  within  the  project  and  resolved 
there  if  possible.  Any  noncompliance  issues  that  cannot  be  resolved  within  the  project  are  escalated 
to  an  appropriate  level  of  management  for  resolution. 

Process  and  Product  Quahty  Assurance  can  best  be  described  by  the  following  goals  and  practices. 
Goals  are  shown  in  bold  and  practices  are  numbered  sequentiaUy  below  each  goal. 

1.  Adherence  of  the  performed  process  and  associated  work  products  and  services  to  applica¬ 
ble  process  descriptions,  standards,  and  procedures  is  objectively  evaluated. 

1 . 1  Objectively  evaluate  the  designated  performed  processes  against  the  applicable  process 
descriptions,  standards,  and  procedures. 

1 .2  Objectively  evaluate  the  designated  work  products  and  services  against  the  applicable 
process  descriptions,  standards,  and  procedures. 
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2.  Noncompliance  issues  are  objectively  tracked  and  communicated,  and  resolution  is  ensured. 

2. 1  Communicate  quality  issues  and  ensure  resolution  of  noncompliance  issues  with  the  staff 
and  managers. 

2.2  Establish  and  maintain  records  of  the  quality  assurance  activities. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Process  and  Product  Quality  Assurance, 
see  the  source  documents  referenced  in  the  bibliography. 

2.8  Project  Monitoring  and  Controi 

The  purpose  of  Project  Monitoring  and  Control  is  to  provide  an  understanding  of  the  project’s  pro- 
gress  so  that  appropriate  corrective  actions  can  be  taken  when  the  project’s  performance  deviates 
significantly  from  the  plan. 

For  acquisition,  monitoring  and  control  Junctions  are  directed  within  the  acquisition  project  early  in  the  process  as  the 
acquisition  planning  is  performed  and  the  strategy  is  defined.  As  the  acquisition  process  unfolds,  monitoring  and  com 
trolling  are  essential  to  ensuring  that  appropriate  resources  are  being  applied  and  that  internal  acquisition  activities 
are  progressing  according  to  plan.  Project  monitoring  and  control  involves  establishing  the  planned  internal  activities 
and  schedule  for  completion  and  then  monitoring  the  status  of  these  activities  and  work  product  completions  through 
measurement  and  analysis  (metrics).  It  is  important  that  the  acquisition  project  has  internal  processes,  plans,  and  work 
products  that  are  monitored  for  satisfactory  completion  and  progress. 

Included  in  those  internal  items  monitored  should  be  work  product  completion  (specifications,  plans.  Request  for  PrO' 
posal  components,  etc),  staffing  levels  and  qualifications  applied,  system  performance  objectives  and  thresholds,  infra¬ 
structure  readiness  (tools,  networks,  etc.)  and  other  activities  and  products  included  in  project  planning.  Project  risk 
should  be  actively  identified  and  managed  (mitigated)  as  well. 

Corrective  action  should  be  applied  when  execution  does  not  match  project  planning  (e.g.,  internal  staffing,  project  plan 
completion  dates,  draft  and  final  solicitation  and  contract  award  milestone  date  slippages). 

If  a  corrective  action  is  required  to  resolve  variances  from  project  plans,  these  actions  should  be  defined  and  tracked  to 
closure. 

Once  a  supplier  is  selected  and  an  award  is  made,  the  role  of  monitoring  and  control  becomes  twofold,  concerned  with 
continuing  to  monitor  and  control  internally  while  also  monitoring  and  controlling  the  progress  of  the  supplier’s  execu¬ 
tion  under  the  supplier’s  project  plan.  The  goals  and  practices  described  in  this  process  area  are  equally  applicable  to 
monitoring  and  controlling  the  acquirer’s  internal  activities  and  monitoring  and  controlling  the  supplier’s  activities 
after  a  contract  is  executed.  The  acquirer  should  monitor  the  supplier’s  establishment  of  a  project  plan  that  will  effec¬ 
tively  complete  the  contract  as  reflected  in  the  contractual  agreement  and  the  supplier’s  implementation  of  processes 
that  will  successfully  execute  that  plan. 

A  project's  documented  plan  is  the  basis  for  monitoring  activities,  communicating  status,  and  taking 
corrective  action.  Progress  is  primarily  determined  by  comparing  actual  work  product  and  task  at¬ 
tributes  effort,  cost,  and  schedule  to  the  plan  at  prescribed  milestones  or  control  levels  within  the 
project  schedule  or  work  breakdown  structure.  Appropriate  visibility  enables  timely  corrective  ac¬ 
tion  to  be  taken  when  performance  deviates  significantly  from  the  plan.  A  deviation  is  significant  if, 
when  left  unresolved,  it  precludes  the  project  from  meeting  its  objectives. 
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The  term  “project  plan"  is  used  throughout  these  practices  to  refer  to  the  overall  plan  for  controlling 
the  project. 

When  actual  status  deviates  significantly  from  the  expected  values,  corrective  actions  are  taken  as 
appropriate.  These  actions  may  require  re-planning,  which  may  include  revising  the  original  plan, 
establishing  new  agreements,  or  including  additional  mitigation  activities  within  the  current  plan. 

Project  Monitoring  and  Control  can  best  be  described  by  the  following  goals  and  practices.  Goals  are 
shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  Actual  performance  and  progress  of  the  project  are  monitored  against  the  project  plan. 

1 . 1  Monitor  the  actual  values  of  the  project  planning  parameters  against  the  project  plan. 

1 .2  Monitor  commitments  against  those  identified  in  the  project  plan. 

1 .3  Monitor  risks  against  those  identified  in  the  project  plan. 

1 .4  Monitor  the  management  of  project  data  against  the  project  plan. 

1 .5  Monitor  stakeholder  involvement  against  the  project  plan. 

1 .6  Periodically  review  the  project’s  progress,  performance,  and  issues. 

1.7  Review  the  accomplishments  and  results  of  the  project  at  selected  project  milestones. 

2.  Corrective  actions  are  managed  to  closure  when  the  project’s  performance  or  results  devi¬ 
ate  significantly  from  the  plan. 

2. 1  Collect  and  analyze  the  issues  and  determine  the  corrective  actions  necessary  to  address  the 
issues. 

2.2  Take  corrective  action  on  identified  issues. 

2.3  Manage  corrective  actions  to  closure. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Project  Monitoring  and  Control,  see  the 
source  documents  referenced  in  the  bibhography. 

2.9  Project  Planning 

The  purpose  of  Project  Planning  is  to  establish  and  maintain  plans  that  define  project  activities. 

For  acquisition,  project  planning  starts  by  setting  the  acquisition  strategy  and  is  followed  by  planning  the  acquisition 
process  in  ever-increasing  levels  of  detail  As  the  acquisition  proceeds  toward  selection  of  a  supplier,  the  supplier’s  plan¬ 
ning  process  should  be  reviewed  for  sufficiency.  The  resulting  plans  should  also  be  reviewed  for  consistency  with  the  sys¬ 
tem  acquisition  plans.  The  acquirer’s  and  developer’s  project  planning  processes  are  continuous  and  the  plans  evolve  to 
meet  the  projects’  needs. 

If  there  is  an  existing  system  to  be  replaced  as  part  of  the  acquisition,  the  acquirer  may  be  required  to  consider  transi¬ 
tion  from  operation  and  disposal  of  the  existing  system  as  part  of  the  planning  for  executing  the  new  system.  Any  such 
transition  activities  should  be  included  in  the  project  plan  and  provision  for  accommodation  of  such  specialized  re¬ 
quirements  should  be  included.  It  may  be  beneficial  to  refer  to  paragraph  2.14,  Transition  to  Operations  and  Support, 
when  planning. 

When  integrated  teams  are  formed,  ensure  the  following: 
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•  Project  data  includes  data  developed  and  used  solely  within  a  particular  team  as  well  as  data  applicable  across 
integrated  team  boundaries,  if  there  are  multiple  integrated  teams. 

•  Planning  for  project  resources  must  consider  staffing  of  the  integrated  teams. 

•  Stakeholder  involvement  must  be  planned  down  to  the  integrated  team  level. 

•  The  integrated  teams'  integrated  work  plans  are  among  the  plans  to  review. 

•  Special  attention  must  be  paid  to  resource  commitments  whenever  there  are  distributed  integrated  teams  and 
whenever  people  are  on  multiple  integrated  teams  in  one  or  many  projects. 

•  The  integrated  team  plans  must  get  buy  An  from  the  team  members,  the  interfacing  teams,  the  project,  and  the  proc' 
ess  owners  of  the  standard  processes  that  team  has  selected  for  tailored  application. 

The  Project  Planning  process  area  involves  the  following; 

•  developing  the  proj  ect  plan 

•  interacting  with  stakeholders  appropriately 

•  getting  commitment  to  the  plan 

•  maintaining  the  plan 

Planning  begins  with  requirements  that  define  the  product  and  project. 

Planning  includes  estimating  the  attributes  of  the  work  products  and  tasks,  determining  the  re¬ 
sources  needed,  negotiating  commitments,  producing  a  schedule,  and  identifying  and  analyzing  pro¬ 
ject  risks.  Iterating  through  these  activities  may  be  necessary  to  establish  the  project  plan.  The  pro¬ 
ject  plan  provides  the  basis  for  performing  and  controlling  the  project’s  activities  that  address  the 
commitments  with  the  project’s  customer. 

The  project  plan  wiU  usually  need  to  be  revised  as  the  project  progresses  to  address  changes  in  re¬ 
quirements  and  commitments,  inaccurate  estimates,  corrective  actions,  and  process  changes.  Specific 
practices  describing  both  planning  and  re-planning  are  contained  in  this  process  area. 

Project  Planning  can  best  be  described  by  the  following  goals  and  practices.  Goals  are  shown  in  bold 
and  practices  are  numbered  sequentially  below  each  goal. 

1.  Estimates  of  project  planning  parameters  are  established  and  maintained. 

1 . 1  Establish  a  top-level  work  breakdown  structure  (WBS)  to  estimate  the  scope  of  the  project. 

1 .2  Establish  and  maintain  estimates  of  the  attributes  of  the  work  products  and  tasks. 

1.3  Define  the  project  life-cycle  phases  upon  which  to  scope  the  planning  effort. 

1 .4  Estimate  the  project  effort  and  cost  for  the  work  products  and  tasks  based  on  estimation 
rationale. 

2.  A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the  project. 

2. 1  Establish  and  maintain  the  project’s  budget  and  schedule. 

2.2  Identify  and  analyze  project  risks. 

2.3  Plan  for  the  management  of  project  data. 

2.4  Plan  for  necessary  resources  to  perform  the  project. 
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2.5  Plan  for  knowledge  and  skills  needed  to  perform  the  project. 

2.6  Plan  the  involvement  of  identified  stakeholders. 

2.7  Establish  and  maintain  the  overall  project  plan  content. 

3.  Commitments  to  the  project  plan  are  established  and  maintained. 

3 . 1  Review  all  plans  that  affect  the  project  to  understand  proj  ect  commitments. 

3.2  Reconcile  the  project  plan  to  reflect  available  and  estimated  resources. 

3.3  Obtain  commitment  from  relevant  stakeholders  responsible  for  performing  and  supporting 
plan  execution. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Project  Planning,  see  the  source  docu' 
ments  referenced  in  the  bibliography. 

2.10  Requirements  Development 

The  purpose  of  Requirements  Development  is  to  produce  and  analyze  customer,  product,  and  prod' 
uct'component  requirements. 

For  acquisition,  Requirements  Development  has  two  contexts.  The  first  context  is  the  amalgamation  and  coordination 
of  the  operational  requirements  (i.e.,  customer  requirements)  into  a  set  of  requirements  that  will  define  the  scope  and 
direction  of  the  acquisition.  The  second  context  is  the  allocation  and  extension  of  the  customer  requirements  and  addy 
tional  acquirer  requirements  (e.g.,  architecture  requirements,  formal  and  informal  review  requirements,  reporting  re¬ 
quirements,  or  data  requirements)  that  become  the  basis  of  the  processes  utilized  by  the  supplier's  organization. 

There  is  a  continuous  iteration  of  requirements  down  through  the  multiple  tiers  of  requirements  documents  associated 
with  the  components  of  a  system.  For  example,  requirements  flow  from  the  stakeholders  to  the  system  level  to  multiple 
subsystem  levels  and  eventually  to  either  hardware  or  software  component  levels.  The  responsibility  for  developing  re¬ 
quirements  across  the  levels  is  generally  split  between  the  acquirer  and  the  supplier.  The  acquirer  is  generally  responsible 
for  the  higher  level,  starting  with  operational  requirements  and  the  supplier  is  responsible  for  successive  levels  below 
that 

As  each  level  of  requirements  is  defined  there  is  an  iterative  process  of  allocation,  high-level  design,  and  requirements 
definition  (for  the  next  lower  level). 

The  acquirer  is  responsiblefor  defining  and  baselining  the  requirements  levels  under  their  control  and  also  monitoring 
the  supplier  definition  of  lower  level  requirements,  reviewing  and  assuring  that  the  work  products  associated  with  the 
requirements  are  being  produced  It  is  also  the  responsibility  of  the  acquirer  to  monitor  the  lower  level  requirements 
development  process  to  assure  the  requirements  contained  at  each  level  will  produce  a  system  that  will  satisfy  the  overall 
system  and  operational  requirements. 

Requirements  include  not  only  the  classical  Junctional  and  performance  requirements,  but  also  interface  requirements, 
whether  they  are  contained  in  a  separate  interface  specification  or  contained  within  the  requirements  specification. 

Requirements  also  include  non-functional  requirements  such  as  data  rights,  delivery  dates,  milestone  exit  criteria,  and 
other  attributes  such  as  evolvability,  maintainability,  and  re-usability,  which  can  drive  the  definition  of  the  product 
requirements. 
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When  acquiring  services  instead  of  products,  the  same  requirements  process  is  used  to  define  highAevel  operational  needs 
and  to  allocate  those  needs  to  lower  level  components  of  the  service  to  ensure  the  resulting  service  meets  the  original  in¬ 
tent. 

Requirements  Development  describes  three  types  of  requirements:  customer  requirements,  product 
requirements,  and  product-component  requirements.  Taken  together,  these  requirements  address 
the  needs  of  relevant  stakeholders,  including  those  pertinent  to  various  product  life-cycle  phases 
(e.g.,  verification  criteria)  and  product  attributes  (e.g.,  safety,  rehability,  and  maintainability). 

This  process  area  addresses  all  customer  requirements  rather  than  only  product-level  requirements 
because  the  customer  may  also  provide  specific  design  requirements. 

Requirements  are  identified  and  refined  throughout  the  phases  of  the  product  life  cycle.  Design  deci¬ 
sions,  subsequent  corrective  actions,  and  feedback  during  each  phase  of  the  product’s  life  cycle  are 
analyzed  for  impact  on  allocated  and  derived  requirements. 

Analyses  are  used  by  both  the  acquirer  and  the  supplier  to  understand,  define,  and  select  the  re¬ 
quirements  at  aU  levels  from  competing  alternatives.  These  analyses  include  the  following; 

•  analysis  of  needs  and  requirements  for  each  product  life-cycle  phase,  including  needs  of  relevant 
stakeholders,  the  operational  environment,  and  factors  that  reflect  overall  customer  and  end-user 
expectations  and  satisfaction,  such  as  safety,  security,  and  affordability 

•  development  of  an  operational  concept 

•  definition  of  the  required  functionality 

After  award  to  a  supplier,  analyses  occur  recursively  at  successively  more  detailed  layers  of  a  prod¬ 
uct’s  architecture  until  sufficient  detail  is  available  to  enable  detailed  design,  implementation,  and 
testing  of  the  product  to  proceed.  As  a  result  of  the  analysis  of  requirements  and  the  operational  con¬ 
cept  (including  functionality,  support,  maintenance,  and  disposal),  the  manufacturing  or  production 
concept  produces  more  derived  requirements,  including  consideration  of  the  following: 

•  constraints  of  various  types 

•  technological  limitations 

•  cost  and  cost  drivers 

•  time  constraints  and  schedule  drivers 

•  risks 

•  consideration  of  issues  implied  but  not  explicitly  stated  by  the  customer  or  end  user 

•  factors  introduced  by  the  supplier’s  unique  business  considerations,  regulations,  and  laws 

Involvement  of  relevant  stakeholders  in  both  requirements  development  and  analysis  gives  them 
visibility  into  the  evolution  of  requirements.  This  activity  continually  assures  that  the  requirements 
are  being  properly  defined. 

Requirements  Development  can  best  be  described  by  the  foUnwlng  goals  and  practices.  Goals  are 
shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 
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1.  stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and  translated  into 
customer  requirements. 

1 . 1  Elicit  stakeholder  needs,  expectations,  constraints,  and  interfaces  for  all  phases  of  the 
product  life  cycle. 

1 .2  Transform  stakeholder  needs,  expectations,  constraints,  and  interfaces  into  customer 
requirements. 

2.  Customer  requirements  are  refined  and  elaborated  to  develop  product  and  product- 
component  requirements. 

2. 1  Establish  and  maintain  product  and  product-component  requirements,  which  are  based  on 
the  customer  requirements. 

2.2  Allocate  the  requirements  for  each  product  component. 

2.3  Identify  interface  requirements. 

3. .  The  requirements  are  analyzed  and  validated,  and  a  definition  of  required  functionality  is 
developed. 

3. 1  Establish  and  maintain  operational  concepts  and  associated  scenarios. 

3.2  Establish  and  maintain  a  definition  of  required  functionality. 

3.3  Analyze  requirements  to  ensure  that  they  are  necessary  and  sufficient. 

3.4  Analyze  requirements  to  balance  stakeholder  needs  and  constraints. 

3.5  Validate  requirements  to  ensure  the  resulting  product  will  perform  as  intended  in  the  user’s 
environment  using  multiple  techniques  as  appropriate. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Requirements  Development,  see  the 
source  documents  referenced  in  the  bibliography. 

2.11  Requirements  Management 

The  purpose  of  Requirements  Management  is  to  manage  the  requirements  of  the  project's  products 
and  product  components  and  to  identify  inconsistencies  between  those  requirements  and  the  pro- 
ject's  plans  and  work  products. 

For  acquisition,  requirements  management  is  applied  to  the  requirements  that  are  received  from  the  requirements  deveF 
opment  process.  During  the  acquisition,  requirements  management  includes  the  direct  management  of  acquirer- 
controlled  requirements  and  oversight  of  supplier  requirements  management.  Requirements  are  managed  and  main¬ 
tained  with  discipline  so  that  changes  are  not  executed  without  recognizing  the  impact  to  the  project. 

Requirements  management  should  define  “approved"  requirements  providers  and  an  approved  path  by  which  require¬ 
ments  arc  provided  to  the  supplier.  This  definition  prevents  suppliers  from  receiving  requirements  changes  from  unau¬ 
thorized  sources  that  are  outside  the  flow  of  the  acquirer’s  established  requirements  management  process. 

Commitment  to  the  requirements  by  the  project  participants  includes  having  coordinated  and  approved  documents  that 
define  requirements. 

Each  change  to  a  controlled  requirement  should  be  assessed  for  impact  to  the  project’s  performance,  cost,  and  schedule 
baselines  and  to  project  risk.  The  existing  cost,  schedule,  and  performance  baselines  should  be  changed,  as  required,  to 
accommodate  the  requirements  change. 
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Requirements  management  processes  manage  all  requirements  received  or  generated  by  the  project, 
including  both  technical  and  non'technical  requirements  as  well  as  those  requirements  levied  on  the 
project  by  the  organization.  In  particular,  if  the  Requirements  Development  process  area  is  impk' 
mented,  its  processes  will  generate  product  and  product-component  requirements  that  will  also  be 
managed  by  the  requirements  management  processes.  When  the  Requirements  Management,  Re¬ 
quirements  Development,  and  Technical  Solution  process  areas  are  aU  implemented,  their  associated 
processes  may  be  closely  tied  and  be  performed  concurrently. 

The  project  takes  appropriate  steps  to  ensure  that  the  agreed-upon  set  of  requirements  is  managed  to 
support  the  planning  and  execution  needs  of  the  project.  When  a  project  receives  requirements  from 
an  approved  requirements  provider,  the  requirements  are  reviewed  with  the  requirements  provider 
to  resolve  issues  and  prevent  misunderstanding  before  the  requirements  are  incorporated  into  the 
project’s  plans.  Once  the  requirements  provider  and  the  requirements  receiver  reach  an  agreement, 
commitment  to  the  requirements  is  obtained  from  the  project  participants.  The  project  manages 
changes  to  the  requirements  as  they  evolve  and  identifies  any  inconsistencies  that  occur  among  the 
plans,  work  products,  and  requirements. 

Part  of  the  management  of  requirements  is  to  document  requirements  changes  and  rationale  and 
maintain  bidirectional  traceability  between  source  requirements  and  all  product  and  product- 
component  requirements. 

Requirements  Management  can  best  be  described  by  the  following  goals  and  practices.  Goals  are 
shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  Requirements  are  managed  and  inconsistencies  with  project  plans  and  work  products  are 
identified. 

1 . 1  Develop  an  understanding  with  the  requirements  providers  on  the  meaning  of  the 
requirements. 

1 .2  Obtain  commitment  to  the  requirements  from  the  project  participants. 

1 .3  Manage  changes  to  the  requirements  as  they  evolve  dming  the  project. 

1.4  Maintain  bidirectional  traceability  among  the  requirements  and  the  project  plans  and  work 
products. 

1 .5  Identify  inconsistencies  between  the  project  plans  and  work  products  and  the  requirements. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Requirements  Management,  see  the 
source  documents  referenced  in  the  bibhography. 

2.12  Risk  Management 

The  purpose  of  Risk  Management  is  to  identify  potential  problems  before  they  occur,  so  that  risk- 
handling  activities  may  be  planned  and  invoked  as  needed  across  the  life  of  the  product  or  project  to 
mitigate  adverse  impacts  on  achieving  objectives. 

For  acquisition,  risk  identification  and  estimation  of  probability  and  impact,  particularly  the  risk  involved  in  meeting 
performance  requirements,  schedules,  and  cost  targets,  largely  determines  the  acquisition  strategy.  The  acquirer  has  a 
dual  role:  first,  in  assessing  and  managing  overall  project  risks  for  the  duration  of  the  project,  and  second,  in  assessing 
and  managing  risks  associated  with  the  performance  of  the  supplier.  As  the  acquisition  progresses  to  the  selection  of  a 
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supplier,  the  risk  specific  to  the  supplier’s  technical  and  management  approach  then  becomes  important  to  the  success  of 
the  acquisition. 

The  particular  risks  associated  with  conducting  the  project  using  integrated  teams  should  be  considered,  such  as  risks 
associated  with  loss  of  inter-team  or  intra-team  coordination. 

Risk  management  is  a  continuous,  forward-looking  process  that  is  an  important  part  of  business  and 
technical  management  processes.  Risk  management  should  address  issues  that  could  endanger 
achievement  of  critical  objectives.  A  continuous  risk  management  approach  is  applied  to  effectively 
anticipate  and  mitigate  the  risks  that  have  critical  impact  on  the  project. 

Effective  risk  management  includes  early  and  aggressive  risk  identification  through  the  collaboration 
and  involvement  of  relevant  stakeholders,  as  described  in  the  stakeholder  involvement  plan  ad¬ 
dressed  in  the  Project  Planning  process  area.  Strong  leadership  across  all  relevant  stakeholders  is 
needed  to  establish  an  environment  for  the  free  and  open  disclosure  and  discussion  of  risk. 

While  technical  issues  are  a  primary  concern  both  early  on  and  throughout  all  project  phases,  risk 
management  should  consider  both  internal  and  external  sources  for  cost,  schedule,  and  technical 
risk.  Early  and  aggressive  detection  of  risk  is  important  because  it  is  typically  easier,  less  costly,  and 
less  disruptive  to  make  changes  and  correct  work  efforts  during  the  earlier,  rather  than  the  later, 
phases  of  the  project. 

Risk  management  can  be  divided  into  three  parts;  defining  a  risk  management  strategy;  identifying 
and  analyzing  risks;  and  handling  identified  risks,  including  the  implementation  of  risk  mitigation 
plans  when  needed. 

As  represented  in  the  Project  Planning  and  Project  Monitoring  and  Control  process  areas,  organiza¬ 
tions  may  initially  focus  simply  on  risk  identification  for  awareness,  and  react  to  the  realization  of 
these  risks  as  they  occur.  The  Risk  Management  process  area  describes  an  evolution  of  these  specific 
practices  to  systematically  plan,  anticipate,  and  mitigate  risks  to  proactively  minimize  their  impact 
on  the  project. 

Although  the  primary  emphasis  of  the  Risk  Management  process  area  is  on  the  project,  the  concepts 
may  also  be  applied  to  manage  organizational  risks. 

Risk  Management  can  best  be  described  by  the  following  goals  and  practices.  Goals  are  shown  in 
bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  Preparation  for  risk  management  is  conducted. 

1 . 1  Determine  risk  sources  and  categories. 

1 .2  Define  the  parameters  used  to  analyze  and  categorize  risks,  and  the  parameters  used  to 
control  the  risk  management  effort. 

1 .3  Establish  and  maintain  the  strategy  to  be  used  for  risk  management. 

2.  Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

2. 1  Identify  and  document  the  risks. 

2.2  Evaluate  and  categorize  each  identified  risk  using  the  defined  risk  categories  and  parameters, 
and  determine  its  relative  priority. 
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3.  Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse  impacts  on  achiev¬ 
ing  objectives. 

3.1  Develop  a  risk  mitigation  plan  for  the  most  important  risks  to  the  project,  as  defined  by  the 
risk  management  strategy. 

3.2  Monitor  the  status  of  each  risk  periodically  and  implement  the  risk  mitigation  plan  as 
appropriate. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Risk  Management,  see  the  source  docu' 
ments  referenced  in  the  bibliography. 

2.13  Solicitation  and  Contract  Monitoring 

The  purpose  of  Solicitation  and  Contract  Monitoring  is  to  prepare  a  solicitation  package  that  identi' 
fies  the  needs  of  a  particular  acquisition,  to  select  a  suppher  that  is  best  capable  of  satisfying  those 
needs,  and  to  provide  leadership  throughout  the  life  of  the  acquisition  to  ensure  those  needs  are  met. 

For  acquisition,  the  solicitation  must  comply  with  the  applicable  federal,  departmental,  and  service  acquisition  reguh' 
tions  and  policies.  The  solicitation  should  address  issues  appropriate  to  the  system  domain  or  acquisition  environment 
(e.g.,  supplier  process  evaluations,  operational  safety  suitability  and  effectiveness,  safety,  certifications,  architecture 
evaluations,  and  interoperability).  The  representatives  responsible  for  thesefunctional  disciplines  within  the  project  or 
stakeholder  organizations  should  be  consulted  for  proper  inclusion  of  those  disciplines  into  the  solicitation  and  contract 
monitoring  process. 

When  integrated  teams  are  formed,  team  membership  should  be  negotiated  with  suppliers  and  incorporated  into  the 
agreement.  The  agreement  should  identify  integrated  decisiommaking,  reporting  requirements  (i.e.,  business  and  techni' 
cal),  and  trade  studies  requiring  supplier  involvement.  The  supplier  efforts  should  be  orchestrated  to  support  the  IPPD 
efforts  undertaken  by  the  acquirer. 

The  Solicitation  and  Contract  Monitoring  process  area  is  intended  to  create  a  proactive  environment 
to  enable  the  acquirer  to  initiaUze  and  adapt  the  relationship  with  the  suppher  over  the  duration  of 
that  relationship  for  the  successful  execution  of  the  project.  In  addition,  it  is  intended  to  encourage 
creation  of  a  contract  that  will  enable  the  acquirer  to  execute  its  monitoring  and  control  of  supplier 
activities  using  other  process  areas,  such  as  Project  Monitoring  and  Control.  This  encouragement 
may  include  levying  a  contractual  requirement  on  the  suppher  to  create  a  project  plan  that  wOl  sue- 
cessfuUy  execute  the  contract,  to  define  and  execute  the  processes  needed  to  achieve  success,  and  to 
commit  to  execute  their  plan  as  it  evolves  during  contract  execution. 

The  Solicitation  and  Contract  Monitoring  process  area  involves  planning  for  and  performing  the 
practices  necessary  to  develop  and  issue  a  soheitation  package,  preparing  for  the  evaluation  of  re' 
sponses,  conducting  an  evaluation,  conducting  supporting  negotiations,  making  recommendations 
for  award  of  the  contract,  and  overseeing  the  execution  phase  to  ensure  the  needs  of  the  acquisition 
are  met. 

The  acquirer  and  suppher  establish  and  maintain  a  mutual  understanding  through  effective,  timely, 
and  appropriate  communication.  The  acquirer  should  clearly  identify  and  prioritize  its  needs  and 
expectations,  as  well  as  its  supphers’  hmitations.  The  acquirer  works  closely  with  supphers  to 
achieve  a  mutual  understanding  of  product  requirements,  responsibilities,  and  processes  that  will  be 
applied  to  achieve  project  objectives. 
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Solicitation  and  Contract  Monitoring  can  best  be  described  by  the  following  goals  and  practices. 
Goals  are  shown  in  bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  The  project  is  prepared  to  conduct  the  solicitation. 

1 . 1  Designate  a  selection  official  responsible  for  making  the  selection  decision. 

1.2  Establish  and  maintain  a  solicitation  package  that  includes  the  needs  of  the  acquisition  and 
corresponding  proposal  evaluation  criteria. 

1.3  Establish  and  maintain  independently  reviewed  cost  and  schedule  estimates  for  the  products 
to  be  acquired. 

1 .4  Validate  the  solicitation  package  with  end  users  and  potential  bidders  to  ensure  the  approach 
and  cost  and  schedule  estimates  are  realistic  and  can  reasonably  lead  to  a  usable  product. 

2.  Suppliers  are  selected  based  on  the  solicitation  package. 

2. 1  Evaluate  proposals  according  to  the  documented  solicitation  plans. 

2.2  Use  proposal  evaluation  results  as  a  basis  to  support  selection  decisions. 

3.  Contracts  are  issued  based  on  the  needs  of  the  acquisition  and  the  suppliers’  proposed  ap¬ 
proaches. 

3.1  Establish  and  maintain  a  mutual  understanding  of  the  contract  with  selected  suppliers  and 
end  users  based  on  the  acquisition  needs  and  the  suppliers’  proposed  approaches. 

3.2  Establish  and  maintain  communication  processes  and  procedures  with  suppliers  that 
emphasize  the  needs,  expectations,  and  measures  of  effectiveness  to  be  used  throughout  the 
acquisition. 

4.  Work  is  coordinated  with  suppliers  to  ensure  the  contract  is  executed  properly. 

4. 1  Monitor  and  analyze  selected  processes  used  by  the  supplier  based  on  the  supplier’s 
documented  processes. 

4.2  Evaluate  selected  supplier  work  products  based  on  documented  evaluation  criteria. 

4.3  Revise  the  supplier  agreement  or  relationship,  as  appropriate,  to  reflect  changes  in 
conditions. 

For  more  extensive  treatment  of  the  goals  and  practices  of  SoUcitation  and  Contract  Monitoring,  see 
the  source  documents  referenced  in  the  bibliography. 

2.14  Transition  to  Operations  and  Support 

.The  purpose  of  Transition  to  Operations  and  Support  is  to  provide  for  the  transition  of  the  product 
to  the  end  user  and  the  eventual  support  organization  and  to  accommodate  hfc'cycle  evolution. 

For  acquisition,  planning  for  transition  includes  establishing  strategies  for  support  (i.e.,  source  of  repair)  through  or¬ 
ganic  support  infrastructures,  contractor  logistics  support  (CLS),  or  other  sources.  The  roles  and  responsibilities  of  the 
acquirer,  supporter,  and  user  should  be  defined  in  the  life-cycle  support  of  the  system.  The  acquirer  must  determine  if  it 
will  execute  the  function  directly  or  make  provision  for  the  function  to  be  executed  as  a  result  of  the  acquisition  itself 
Responsibility  for  capability  enhancements  during  the  support  phase  should  be  defined,  considering  the  magnitude  and 
complexity  of  the  envisioned  change.  Explicitly  identifying  organizationally  who  has  responsibility  for  support  (ie., 
“level  1  maintenance")  and  for  enhancements  (i.e.,  “level  2  maintenance”)  ensures  that  relevant  stakeholders  are  involved 
early  in  the  acquisition  project’s  planning  processes.  The  acquisition  project  should  also  assign  responsibility  for  imple- 
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mentation  of  the  practices  identified  in  this  process  area  (see  generic  practice  discussion  in  Section  3  of  this  document). 
Additionally,  the  acquisition  project  must  work  with  the  operational  units  to  plan  for  transition  of  the  products  into 
operational  use.  This  planning  includes  identifying  and  providing  for  initial  spares,  operational  training  capabilities, 
etc.  Eventual  disposal  of  the  product  should  also  be  considered. 

Transition  to  Operations  and  Support  involves  the  processes  used  to  plan  for  and  manage  the  transi- 
tion  of  new  or  evolved  products  into  operational  use  and  their  transition  to  the  eventual  maintenance 
or  support  organization.  Identify  any  special  conditions  that  may  apply  during  the  eventual  decom' 
missioning  or  disposal  of  the  products.  The  acquisition  project  is  responsible  for  ensuring  the  aC' 
quired  products  not  only  meet  specified  requirements  (see  the  Verification  section)  and  can  be  used 
in  its  intended  environment  (see  the  Validation  section),  but  also  that  they  can  be  transitioned  into 
operational  use  to  achieve  the  users’  desired  mission  capabilities  and  be  maintained  and  sustained 
over  their  intended  life  cycles.  The  acquisition  project  is  responsible  for  ensuring  reasonable  planning 
for  transition  into  operations  is  conducted,  clear  transition  criteria  exist  and  are  agreed  to  by  all  rele- 
vant  stakeholders,  and  products  are  maintained  and  supported  once  operational.  These  plans  include 
reasonable  accommodation  for  known  and  potential  evolution  of  the  products  and  their  eventual 
removal  from  operational  use. 

Transition  to  Operations  and  Support  can  best  be  described  by  the  following.  Goals  are  shown  in 
bold  and  practices  are  numbered  sequentially  below  each  goal. 

1.  Preparation  for  transition  to  operations  and  support  is  conducted. 

1 . 1  Establish  and  maintain  a  strategy  for  transition  to  operations  and  support. 

1.2  Establish  and  maintain  plans  for  transitioning  acquired  products  into  operational  use  and 
support. 

1 .3  Establish  and  maintain  training  requirements  for  operational  and  support  personnel. 

1 .4  Establish  and  maintain  initial  and  life-cycle  resource  requirements  for  performing  operations 
and  support. 

1 .5  Identify  and  assign  organizational  responsibility  for  support. 

1 .6  Establish  and  maintain  criteria  for  assigning  responsibility  for  enhancements. 

1 .7  Establish  and  maintain  transition  criteria  for  the  acquired  products. 

2.  Acquired  products  are  transitioned  to  operations  and  support  based  on  transition  criteria. 

2. 1  Evaluate  the  readiness  of  the  acquired  products  to  undergo  transition  to  operations  and 
support. 

2.2  Evaluate  the  readiness  of  the  operational  and  support  personnel  to  undergo  transition  to  the 
acquired  products. 

2.3  Analyze  the  results  of  all  transition  activities  and  identify  appropriate  action. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Transition  to  Operations  and  Support,  see 
the  source  documents  referenced  in  the  bibliography. 


2.15  Validation 

The  purpose  of  Vahdation  is  to  demonstrate  that  a  product  or  product  component  fulfills  its  in- 
tended  use  when  placed  in  its  intended  environment. 


26 


CMU/SEI-2004-TR-001 


For  acquisition,  validation  is  normally  performed  early  and  continuously  throughout  the  acquisition  life  cycle.  The  ac¬ 
quirer  uses  validation  processes  to  demonstrate  that  the  work  products  of  the  acquisition  process  will  fulfill  the  acquisi¬ 
tion  strategy  and  that  the  processes  will  effectively  acquire  the  product  or  services.  The  acquirer  also  uses  validation  to 
ensure  that  the  product  or  service  received  from  the  supplier  will  fulfill  its  intended  use.  In  this  context,  the  test  commu¬ 
nity  is  a  major  stakeholder,  including  up-front  planning  throughfinal-system  validation.  It  is  important  that  the  ac¬ 
quirer  define  at  the  outset  the  degree  to  which  validation  is  required  both  early  in  the  definition  of  the  project  and  later 
when  the  products  are  received.  In  addition,  plans  should  identify  adequate  resources  to  execute  validation  activities. 

Validation  activities  can  be  applied  to  all  aspects  of  the  product  in  any  of  its  intended  environments, 
such  as  operation,  training,  manufacturing,  maintenance,  and  support  services.  The  methods  em- 
ployed  to  accomplish  validation  can  be  applied  to  work  products  as  weU  as  to  the  product  and  prod- 
uct  components.  The  work  products  (e.g.,  requirements,  designs,  prototypes)  should  be  selected  on 
the  basis  of  which  are  the  best  predictors  of  how  well  the  product  and  product  component  will  sat' 
isfy  user  needs. 

The  vahdation  environment  should  represent  the  intended  environment  for  the  product  and  product 
components  as  well  as  represent  the  intended  environment  suitable  for  validation  activities  with 
work  products. 

Validation  demonstrates  that  the  product,  as  provided,  will  fulfill  its  intended  use;  whereas,  verifica' 
tion  addresses  whether  the  work  product  properly  reflects  the  specified  requirements.  In  other 
words,  verification  ensures  that  “^ou  built  it  right;”  whereas,  vahdation  ensures  that  “you  built  the 
right  thing.”  Vahdation  activities  use  approaches  similar  to  verification  (e.g.,  test,  analysis,  inspec¬ 
tion,  demonstration,  or  simulation).  Often,  the  end  users  are  involved  in  the  vahdation  activities. 
Both  vahdation  and  verification  activities  often  run  concurrently  and  may  use  portions  of  the  same 
environment. 

Refer  to  the  Verification  process  area  for  more  information  about  verification  activities. 

Where  possible,  vahdation  should  be  accomphshed  using  the  product  or  product  component  operat¬ 
ing  in  its  intended  environment.  The  entire  environment  may  be  used  or  only  part  of  it.  However, 
vahdation  issues  can  be  discovered  early  in  the  life  of  the  project  using  work  products. 

When  vahdation  issues  are  identified,  they  are  referred  to  the  processes  associated  with  the  Re¬ 
quirements  Development,  Technical  Solution,  or  Project  Monitoring  and  Control  process  areas  for 
resolution. 

The  practices  of  this  process  area  build  on  each  other  in  the  following  way.  Practice  1.1  enables  the 
identification  of  the  product  or  product  component  to  be  validated  and  the  methods  to  be  used  to 
perform  the  vahdation.  Practice  1.2  enables  the  determination  of  the  environment  that  will  be  used  to 
carry  out  the  vahdation.  Practice  1.3  enables  the  development  of  vahdation  procedures  and  criteria 
that  are  aligned  with  the  characteristics  of  selected  products,  customer  constraints  on  vahdation, 
methods,  and  the  vahdation  environment.  Practice  2.1  enables  the  performance  of  vahdation  accord¬ 
ing  to  the  methods,  procedures,  and  criteria. 

Vahdation  can  best  be  described  by  the  foUowing  goals  and  practices.  Goals  are  shown  in  bold  and 
practices  are  numbered  sequentiaUy  below  each  goal. 
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1.  Preparation  for  validation  is  conducted. 

1 . 1  Select  products  and  product  components  to  be  validated  and  the  validation  methods  that  will 
be  used  for  each. 

1 .2  Establish  and  maintain  the  environment  needed  to  support  validation. 

1 .3  Establish  and  maintain  procedures  and  criteria  for  validation. 

2.  The  product  or  product  components  are  validated  to  ensure  that  they  are  suitable  for  use  in 
their  intended  operating  environment. 

2. 1  Perform  validation  on  the  selected  products  and  product  components. 

2.2  Analyze  the  results  of  the  validation  activities  and  identify  issues. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Validation,  see  the  source  documents  reh 
erenced  in  the  bibliography. 

2.16  Verification 

The  purpose  of  Verification  is  to  ensure  that  selected  work  products  meet  their  specified  require- 
ments. 

For  acquisition,  verification  is  normally  paformed  early  and  continuously  throughout  the  acquisition  life  cycle.  The 
acquirer  ensures  that  selected  work  products  of  the  acquisition  process  meet  the  project  requirements  (e.g.,  the  solicitO' 
tion  package  and  other  plans  arc  built  according  to  specified  templates,  meet  all  laws  and  regulations,  and  are  inspected 
for  defects).  The  acquirer  also  ensures  the  evolving  acquired  products  satisfy  contractual  requirements. 

The  Verification  process  area  involves  the  following:  verification  preparation,  verification  perform¬ 
ance,  and  identification  of  corrective  action. 

Verification  processes  include  verification  of  the  product  and  intermediate  work  products  against  all 
selected  requirements,  including  customer,  product,  and  product-component  requirements. 

Verification  is  inherently  an  incremental  process  because  it  occurs  throughout  the  development  of 
the  product  and  work  products,  beginning  with  verification  of  the  requirements,  progressing 
through  the  verification  of  the  evolving  work  products,  and  culminating  in  the  verification  of  the 
completed  product. 

The  specific  practices  of  this  process  area  build  upon  each  other  in  the  following  way:  practice  1.1 
enables  the  identification  of  the  work  products  to  be  verified,  the  methods  to  be  used  to  perform  the 
verification,  and  the  requirements  to  be  satisfied  by  each  selected  work  product.  Practice  1.2  enables 
the  determination  of  the  environment  that  will  be  used  to  carry  out  the  verification.  Practice  1.3  then 
enables  the  development  of  verification  procedures  and  criteria  that  are  aligned  with  the  selected 
work  products,  requirements,  methods,  and  characteristics  of  the  verification  environment.  Practice 
3.1  conducts  the  verification  according  to  the  available  methods,  procedures,  and  criteria. 

Verification  of  work  products  substantially  increases  the  hkehhood  that  the  product  wiU  meet  the 
customer,  product,  and  product-component  requirements. 
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The  Verification  and  Validation  process  areas  are  similar,  but  they  address  different  issues.  Valida¬ 
tion  demonstrates  that  the  product,  as  provided  (or  as  it  will  be  provided),  wiU  fulfill  its  intended 
use,  whereas  verification  addresses  whether  the  work  product  properly  reflects  the  specified  re¬ 
quirements.  In  other  words,  verification  ensures  that  “you  built  it  right;”  whereas,  validation  ensures 
that  “you  built  the  right  thing." 

Product  and  process  inspections,  often  called  peer  reviews,  are  an  important  part  of  verification  and 
are  a  proven  mechanism  for  effective  defect  removal.  An  important  corollary  is  to  develop  a  better 
understanding  of  the  work  products  and  the  processes  that  produced  them  so  defects  can  be  pre¬ 
vented  and  process-improvement  opportunities  can  be  identified. 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the  producers'  peers  to  identify 
defects  and  other  changes  that  are  needed. 

Examples  of  peer  review  methods  include  inspections  and  structured  walkthroughs. 

Verification  can  best  be  described  by  the  following  goals  and  practices.  Goals  are  shown  in  bold  and 
practices  are  numbered  sequentially  below  each  goal. 

1.  Preparation  for  verification  is  conducted. 

1 . 1  Select  the  work  products  to  be  verified  and  the  verification  methods  that  will  be  used  for 
each. 

1 .2  Establish  and  maintain  the  environment  needed  to  support  verification. 

1 .3  Establish  and  maintain  verification  procedures  and  criteria  for  the  selected  work  products. 

2.  Peer  reviews  are  performed  on  selected  work  products. 

2. 1  Prepare  for  peer  reviews  of  selected  work  products. 

2.2  Conduct  peer  reviews  on  selected  work  products  and  identify  issues  resulting  from  the  peer 
review. 

2.3  Analyze  data  about  preparation,  conduct,  and  results  of  the  peer  reviews. 

3.  Selected  work  products  are  verified  against  their  specified  requirements. 

3.1  Perform  verification  on  the  selected  work  products. 

3.2  Analyze  the  results  of  all  verification  activities  and  identify  corrective  action. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Verification,  see  the  source  documents 
referenced  in  the  bibliography. 
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3  Generic  Practices 


Generic  practices  are  practices  that  should  be  included  in  every  process  area  in  addition  to  the  spe¬ 
cific  practices  that  appear  in  each  process  area  description.  The  generic  practices  improve  the  power 
of  a  process  by  assuring  that  the  specific  practices  are  executed  and  that  there  is  appropriate  plan¬ 
ning  of  the  process  to  assure  that  it  is  feasible  and  well-supported.  They  also  ensure  that  stake¬ 
holders  are  properly  involved  in  the  activities  of  the  process.  The  last  two  generic  practices  assure 
that  the  performance  of  each  process  and  the  lessons  learned  are  saved  and  that  this  knowledge  is 
used  to  establish  new  projects  or  to  improve  the  performance  of  an  existing  project. 

Although  a  generic  practice,  by  definition,  apphes  to  aU  process  areas,  the  practical  implications  of 
applying  a  generic  practice  vary  for  each  process  area.  Consider  two  examples  that  illustrate  these 
differences  as  they  relate  to  planning  the  process.  First,  the  planning  described  by  this  generic  prac¬ 
tice  as  applied  to  the  Project  Monitoring  and  Control  process  area  may  be  carried  out  in  full  by  the 
processes  associated  with  the  Project  Planning  process  area.  In  such  a  situation,  the  generic  practice 
imposes  no  additional  expectations  for  planning.  Second,  the  planning  described  by  this  generic 
practice  as  applied  to  the  Project  Planning  process  area  typically  would  not  be  addressed  by  the 
processes  associated  with  other  process  areas  in  the  model.  Therefore,  the  generic  practice  sets  an 
expectation  that  the  project  planning  process  itself  be  plaimed.  It  is  important  to  be  aware  of  the  ex¬ 
tent  to  which  this  generic  practice  may  either  reinforce  expectations  set  elsewhere  in  the  model,  or 
set  new  expectations  that  should  be  addressed. 

1.  Establish  and  maintain  an  organizational  policy  for  planning  and  performing  the  process. 

The  purpose  of  this  generic  practice  is  to  define  the  organizational  expectations  for  the  process  and 
make  these  expectations  visible  to  those  in  the  organization  who  are  affected.  In  general,  senior  man¬ 
agement  is  responsible  for  establishing  and  communicating  guiding  principles,  direction,  and  expec¬ 
tations  for  the  organization. 

Not  all  direction  from  senior  management  will  bear  the  label  “policy.”  The  existence  of  appropriate 
organizational  direction  is  the  expectation  of  this  generic  practice,  regardless  of  what  it  is  called  or 
how  it  is  imparted. 

2.  Establish  and  maintain  the  plan  for  performing  the  process. 

The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to  perform  the  process  and 
achieve  the  established  objectives,  to  prepare  a  plan  for  performing  the  process,  to  prepare  a  process 
description,  and  to  get  agreement  on  the  plan  from  relevant  stakeholders. 

The  objectives  for  the  process  may  be  derived  from  other  plans  (e.g.,  the  project  plans).  Included  are 
objectives  for  the  specific  situation,  including  quality,  cost,  and  schedule  objectives.  For  example,  an 
objective  might  be  to  reduce  the  cost  of  performing  a  process  for  an  implementation  over  its  previous 
implementation. 
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Establishing  a  plan  includes  documenting  the  plan  and  providing  a  process  description.  Maintaining 
the  plan  includes  changing  it  as  necessary  in  response  to  either  corrective  actions  or  to  changes  in 
requirements  and  objectives  for  the  process. 

The  plan  for  performing  the  process  typicahy  includes  the  foUovwng; 

•  process  description 

•  standards  for  the  work  products  and  services  of  the  process 

•  requirements  for  the  work  products  and  services  of  the  process 

•  specific  objectives  for  the  performance  of  the  process  (e.g.,  quality,  time  scale,  cycle  time,  and 
resource  usage) 

•  dependencies  among  the  activities,  work  products,  and  services  of  the  process 

•  resources  (including  funding,  people,  and  tools)  needed  to  perform  the  process 

•  assignment  of  responsibility  and  authority 

•  training  needed  for  performing  and  supporting  the  process 

•  work  products  to  be  placed  under  configuration  management  and  the  level  of  configuration 
management  for  each  item 

•  measurement  requirements  to  provide  insight  into  the  performance  of  the  process,  its  work 
products,  and  its  services 

•  involvement  of  identified  stakeholders 

•  activities  for  monitoring  and  controlling  the  process 

•  objective  evaluation  activities  for  the  process  and  the  work  products 

•  management  review  activities  for  the  process  and  the  work  products 

3.  Provide  adequate  resources  for  performing  the  process,  developing  the  work  products,  and 
providing  the  services  of  the  process. 

The  purpose  of  this  generic  practice  is  to  ensure  that  the  resources  necessary  to  perform  the  .process 
as  defined  by  the  plan  are  available  when  they  are  needed.  Resources  include  adequate  funding,  ap- 
propriate  physical  faciUties,  skilled  people,  and  appropriate  tools. 

4.  Assign  responsibility  and  authority  for  performing  the  process,  developing  the  work 
products,  and  providing  the  services  of  the  process. 

The  purpose  of  this  generic  practice  is  to  ensure  that  there  is  accountability  throughout  the  life  of  the 
process  for  performing  the  process  and  achieving  the  specified  results.  The  people  assigned  should 
have  the  appropriate  authority  to  perform  the  assigned  responsibilities. 

Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in  hving  documents,  such  as  the 
plan  for  performing  the  process.  Dynamic  assignment  of  responsibility  is  another  legitimate  way  to 
perform  this  generic  practice,  as  long  as  the  assignment  and  acceptance  of  responsibiUty  are  ensured 
throughout  the  life  of  the  process. 

5.  Train  the  people  performing  or  supporting  the  process  as  needed. 

The  purpose  of  this  generic  practice  is  to  ensure  that  the  people  have  the  necessary  skills  and  exper¬ 
tise  to  perform  or  support  the  process. 
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Training  supports  the  successful  performance  of  the  process  by  establishing  a  common  understand' 
ing  of  the  process  and  by  imparting  the  skills  and  knowledge  needed  to  perform  the  process. 

6.  Place  designated  work  products  of  the  process  under  appropriate  levels  of  conflguration 
management. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the  integrity  of  the  designated  work 
products  of  the  process  (or  their  descriptions)  throughout  their  useful  hfe. 

The  designated  work  products  are  specifically  identified  in  the  plan  for  performing  the  process,  along 
with  a  specification  of  the  level  of  configuration  management. 

7.  Identify  and  involve  the  relevant  stakeholders  as  planned. 

The  purpose  of  this  generic  practice  is  to  estabhsh  and  maintain  the  expected  involvement  of  stake- 
holders  during  the  execution  of  the  process. 

Involve  relevant  stakeholders  as  described  in  an  appropriate  plan  for  stakeholder  involvement. 

The  objective  of  planning  the  stakeholder  involvement  is  to  ensure  that  interactions  necessary  to  the 
process  are  accomplished,  while  not  allowing  excessive  numbers  of  affected  groups  and  individuals 
to  impede  process  execution. 

8.  Monitor  and  control  the  process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action. 

The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day  monitoring  and  controlling  of 
the  process.  Appropriate  visibility  into  the  process  is  maintained  so  that  appropriate  corrective  ac¬ 
tion  can  be  taken  when  necessary.  Monitoring  and  controlling  the  process  involves  measuring  ap¬ 
propriate  attributes  of  the  process  or  work  products  produced  by  the  process. 

9.  Objectively  evaluate  adherence  of  the  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance. 

The  purpose  of  this  generic  practice  is  to  provide  credible  assurance  that  the  process  is  implemented 
as  planned  and  adheres  to  its  process  description,  standards,  and  procedures. 

10.  Review  the  activities,  status,  and  results  of  the  process  with  higher  level  management  and 
resolve  issues. 

The  purpose  of  this  generic  practice  is  to  provide  higher  level  management  with  the  appropriate  visi¬ 
bility  into  the  process. 

Higher  level  management  includes  those  levels  of  management  in  the  organization  above  the  imme¬ 
diate  level  of  management  responsible  for  the  process.  In  particular,  higher  level  management  in¬ 
cludes  senior  management.  These  reviews  are  for  managers  who  provide  the  pohcy  and  overall  guid¬ 
ance  for  the  process,  not  for  those  who  perform  the  direct  day-to-day  monitoring  and  controlling  of 
the  process. 
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The  two  following  generic  practices  form  the  basis  for  propagating  good  practice  to  future  acquisition  projects.  They  arc 
intended  to  facilitate  process  definition  and  identify  process  benefits  that  encourage  adoption  of  best  practices  on  new 
projects. 

A  defined  process  is  tailored  from  the  organization's  set  of  standard  processes  according  to  the  or- 
ganization’s  tailoring  guidehnes,  and  contributes  work  products,  measures,  and  other  process- 
improvement  information  to  the  organizational  process  assets. 

These  two  generic  practices  activate  a  process  improvement  cycle.  The  organization  maintains  a 
process  asset  library  and  standard  process  that  can  be  drawn  upon  by  a  project  to  create  its  proc¬ 
esses.  In  turn,  the  project  provides  information  about  the  performance  of  its  process  to  the  organiza¬ 
tion’s  process  asset  library  that  is  used  to  improve  and  extend  the  standard  processes. 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the  defined  process,  are  estab¬ 
lished  and  improved  over  time.  Standard  processes  describe  the  fundamental  process  elements  that 
are  expected  in  the  defined  processes.  Standard  processes  also  describe  the  relationships  (e.g.,  the 
ordering  and  interfaces)  between  these  process  elements.  The  organization-level  infrastructure  to 
support  current  and  future  use  of  the  organization's  set  of  standard  processes  is  established  and  im¬ 
proved  over  time. 

11.  Establish  and  maintain  the  description  of  a  defined  process. 

The  purpose  of  this  generic  practice  is  to  estabhsh  and  maintain  a  description  of  the  process  that  is 
tailored  from  the  organization's  set  of  standard  processes  to  address  the  needs  of  a  specific  instantia¬ 
tion.  The  organization  should  have  standard  processes  that  cover  the  process  area,  as  well  as  have 
guidelines  for  tailoring  these  standard  processes  to  meet  the  needs  of  a  project  or  organizational 
function.  With  a  defined  process,  variabihty  in  how  the  processes  are  performed  across  the  organiza¬ 
tion  is  reduced  and  process  assets,  data,  and  learning  can  be  effectively  shared, 

12.  Collect  work  products,  measures,  measurement  results,  and  improvement  information 
derived  from  planning  and  performing  the  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

The  purpose  of  this  generic  practice  is  to  collect  information  and  artifacts  derived  from  planning  and 
performing  the  process.  This  generic  practice  is  performed  so  that  the  information  and  artifacts  can 
be  included  in  the  organizational  process  assets  and  made  available  to  those  who  are  (or  who  will  be) 
planning  and  performing  the  same  or  similar  processes.  The  information  and  artifacts  are  stored  in 
the  organization’s  measurement  repository  and  the  organization’s  process  asset  library. 
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Appendix 


The  series  of  questions  included  in  this  appendix  are  intended  to  aid  acquisition  project  managers 
and  program  executives  in  determining  if  their  projects  are  performing  acquisition  activities  in  ac' 
cordance  with  best  practices.  The  questions  are  intended  to  both  verify  that  best  practices  are  being 
employed  and  to  provide  a  means  of  gathering  the  background  information  necessary  to  determine 
that  the  products  or  services  acquired  are  adequate  and  focused. 

References  to  the  process  areas,  by  document  section  number,  described  in  the  body  of  this  docU' 
ment  are  included  in  parenthesis  after  each  question.  The  questions  especially  focus  on  setting  strat' 
egy  and  on  planning  and  estimating  in  the  belief  that  these  early  activities  determine,  in  large  part, 
the  success  of  an  acquisition  from  the  outset.  Questions  also  focus  on  risk  identification  and  man' 
agement  and  on  capabUities  definition  and  requirements  generation,  as  well  as  on  having  repeatable 
processes  that  enable  organizations  to  institutionalize  best  practices.  The  combination  of  these  ques' 
tions  and  the  process  areas  in  this  document  were  designed  to  facilitate  assessment  and  improve' 
ment  of  the  acquisition  process  in  your  organizations. 


Executive  Guidance  Questions 


1  Do  you  have  an  acquisition  Strategy? 

1 A  How  have  you  determined  it  is  the  most  appropriate  strategy  for  this  acquisition?  (2.2, 2.9, 

2.10, 2.12) 

IB  How  does  your  selected  acquisition  strategy  mitigate  the  risks  you’ve  identified?  (2.9,  2. 12) 

1C  Which  stakeholders  were  involved  in  its  preparation?  (  2.3,  2.4,  2.6,  2.9) 

ID  How  do  your  acquisition  plans  reflect  and  implement  the  acquisition  strategy?  (2.3,  2.9) 

2  Have  you  established  and  maintained  an  acquisition  plan  for  the  program? 

2A  How  did  you  determine  and  document  the  scope  of  the  program?  (2.9,  2.10) 

2B  How  did  you  determine  resource  needs  for  each  element  within  the  scope  of  the  program? 
(2.9) 

2C  How  has  the  program  defined  a  critical  path?  (2.3,  2.9) 

2D  How  has  the  plan  been  coordinated  with  all  relevant  stakeholders  at  both  the  management 
and  working  levels?  ( 2.3,  2.4, 2.6,  2.9) 

2E  How  will  you  ensure  that  you  have  adequate  staff  with  the  necessary  experience  and 
training  to  execute  your  plan?  (2.4,  2.9) 

2F  How  will  you  ensure  that  the  contractor  has  the  resources  and  tools  needed  to  complete  the 
program?  (2.13) 

2G  How  will  you  ensure  the  contractor  has  the  domain  experience  and  process  capability 
needed  to  complete  the  program?  (2.13) 
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3  Have  you  deflned  your  cost,  schedule,  and  performance  baselines? 

3A  How  have  the  cost,  schedule,  and  performance  baselines  been  evaluated  “independently” 
and  from  an  integrated  perspective?  (2.9) 

3B  How  do  you  know  the  baselines  are  realistic  and  executable?  (2.9) 

3C  How  have  you  ensured  all  the  life-cycle  costs  are  included  (e.g.,  training  and  support 
costs)?  (2.9, 2.14) 

3D  How  do  you  use  or  how  do  you  plan  to  use  Earned  Value  Management?  (2.5,  2.8, 2.13) 

3E  What  is  the  role  of  management  reserve  on  your  program?  (2.9) 

3F  What  percentage  of  the  cost  baseline  is  set  aside  for  risk  and  engineering  changes?  (2.9, 

2.11,2.12) 

3G  How  do  you  control  changes  to  the  contractual  requirements?  (2.11,  2. 13) 

3H  How  do  you  accommodate  cost  and  schedule  impacts  due  to  requirements  changes  to 
ongoing  contractual  development  efforts?  (2.8, 2.9,  2. 1 1) 

4  Have  you  validated  your  user  requirements? 

4A  How  do  you  intend  to  keep  the  user  involved  in  the  requirements  process?  (2.3,  2.9,  2. 10, 

2.11.2.13.2.15) 

4B  How  do  you  ensure  a  clear  understanding  exists  of  what  the  user  wants?  (2.10,  2.1 1,  2.13, 

2.15) 

4C  How  do  you  ensure  the  contractor(s)  and  all  relevant  stakeholders  maintain  a  clear 
understanding  of  what  the  user  wants?  (2.10, 2.1 1, 2.13,  2.15) 

4D  What  baselined  documents  capture  that  understanding?  (2.1,  2.10,  2.1 1,  2.13) 

4E  What  role  does  your  organization  play  in  establishing  the  requirements?  (2.3, 2.4, 2. 10) 

4F  What  is  the  strategy  for  keeping  up  with  the  evolving  environment  (e.g.,  threat,  technology, 
process  improvements).  (2.10, 2.1 1, 2.12) 

4G  For  government  developed  or  furnished  equipment  or  software,  are  the  interfaces  welt 
defined?  Is  there  agreement  with  the  contractor  on  interface  specifications  and  function? 
(2.10,  2.13) 

5  How  much  software  do  you  expect  to  be  developed  on  this  program? 

(Note:  The  following  topics  address  software  specific  issues  and  are  appropriate  for  sys¬ 
tems  with  significant  software  challenges.  It  is  also  appropriate  to  address  these  same  ge¬ 
neric  issues  for  other  program  technology  areas.) 

5A  How  have  you  determined  that  the  software  can  be  developed  within  the  allocated  cost  and 
schedule  baselines?  (2.9) 

5B  How  will  the  status  of  software  development  be  monitored?  (2.10) 

5C  What  indicators  are  being  used  to  track  progress  and  performance  for  software  and  systems 
engineering?  (2.5,  2.10) 

5D  Describe  your  strategy  for  incorporating  non-developmental  software  (e.g.,  COTS, 
Government  off-the-shelf  [GOTS],  reuse,  product  lines)  into  the  project.  (2.3,  2.9, 2.10) 

5E  What  percentage  of  the  software  is  planned  to  be  non-developmental  software  (NDS)?  (2.9) 
5F  How  have  you  determined  that  you  can  achieve  the  anticipated  percentage  of  NDS  on  this 
project?  (2.9) 

5G  How  will  you  determine  that  the  projected  NDS  will  provide  the  desired  functionality? 
(2.10,  2.15,2.16) 
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5H  How  will  the  contractor  demonstrate  the  performance  and  stability  of  the  software 
development  environment  and  toots?  (2.13) 

51  Is  there  a  systems  engineering  process  in  place  to  define  software  requirements  and 
software  architectures?  (2.10) 

6  Do  you  have  documented  processes? 

6A  Describe  the  acquisition  areas  covered  by  these  documented  processes.  ( 2.  9,  3.2,  3. 1 1) 

6B  What  mechanism  do  you  use  to  monitor,  control,  and  improve  your  processes?  (2.7, 3.8, 

3.9.3.12) 

6C  Are  your  processes  program  specific  or  are  they  organizational  processes?  Explain.  (3.1, 
3.2,3.11) 

6D  How  do  you  know  you  are  adhering  to  your  processes?  (2.7,  3.8,  3.9,  3.10) 

7  How  do  you  identify  and  manage  risks? 

7A  How  do  you  assess  program  risk?  (2.8,  2.9, 2.12) 

7B  What  risks  have  you  identified  related  to  your  acquisition  plan?  (2.9,  2. 1 2) 

7C  What  are  the  risks  associated  with  schedule?  (2.8,  2.9,  2. 1 2) 

7D  How  have  you  ensured  that  you  understand  the  cost  risk  of  obtaining  the  required 
capability?  (2.8,  2.9,  2.1 1, 2.12) 

7E  What  risks  have  you  identified  related  to  contractor  execution?  (2.8,  2. 12,  2.13) 

7F  What  risks  have  you  identified  that  are  outside  your  control?  (2.12) 

7G  How  do  you  monitor  mitigation  efforts  for  identified  risks?  (2.8,  2. 12) 

7H  Describe  the  risk  management  tool(s)  you  employ.  (2. 1 2,  3 .3) 

71  Who  is  involved  in  program  risk  assessment  (e.g.,  independent  subject  matter  experts)? 
(2.4,  2.12) 

7J  Explain  how  you  have  built  in  sufficient  contingency  to  account  for  program  risk?  (2.2, 2.9, 

2.12) 
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